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Prefacio 


Joca é um apelido carinhoso pelo qual eu chamo o nosso querido 
autor, Joaquim Torres. Brasileiro de destaque na sua área de 
atuação, ele nos presenteia com mais um livro essencial para 
pessoas relacionadas à liderança de produtos digitais. Decidi, 
primeiro, escrever a visão do livro para, depois, contar um pouco 
mais sobre a minha relação com o Joca e sobre a felicidade em ser 
o prefaciador desta obra! 


VISÃO DO LIVRO COMO UM PRODUTO 


Para quem lidera ou se relaciona com líderes de produtos 
digitais, que busca aprimorar conceitos, princípios e ferramentas 
relacionadas ao tema, 


Liderança de produtos digitais: A arte e a ciência da gestão de 
times de produto é o mais novo livro do Joca Torres, que 
compartilha as suas décadas de atuação como líder de produtos 
digitais. 


Diferentemente dos livros gringos, 


o livro compartilha o conhecimento produzido por um dos 
brasileiros mais bem-sucedidos e mais reconhecidos na sua 
área de atuação, de brasileiro para brasileiros. 





Se você está buscando conhecimento e gostaria de uma referência 
fidedigna de alguém que está no Gemba — chão de fábrica — de 
produtos digitais, e também tem uma carreira exemplar no tema 
apresentado no livro, você fez uma excelente escolha! 


Eu, assim como você, busco conhecimento nesse assunto. Aliás, 
liderança em produtos digitais é uma das áreas onde eu sigo 
querendo aprender cada vez mais. São muitos conceitos, muitos 
princípios e muitas ferramentas. Precisamos entender uma grande 


gama de assuntos. Por isso, quero ja agradecer ao Joca pelo 
excelente material que ele compartilhou aqui! 


Entretanto, produto digital, ou pelo menos a liderança em produtos 
digitais, é algo relativamente recente, isso não existia no velho 
mundo. Sim, lembra do velho mundo? Aquele no qual PM era 
abreviação para Project Manager, e não para Product Manager. 
Aquele velho mundo no qual as teorias e vivências práticas na área 
de gestão de produtos eram reduzidas, um privilégio para poucas 
pessoas (algumas até chamadas de gênios). E mesmo nessas 
ocasiões, ainda se falava bem pouco sobre liderança. 
Especialmente se compararmos com a quantidade de conteúdo 
sobre gestão de projetos que já existia e que foi amplamente 
utilizada, comercializada e reconhecida no último século. 


Felizmente, o Joca sempre esteve a frente desta liderança, 
demonstrando a importância — e o sucesso — do P de produto. Ele 
representou, estruturou e liderou muito bem as áreas de gestão de 
produtos por todas as empresas e organizações pelas quais passou. 


Em 2010, quando voltei a morar no Brasil depois de quase uma 
década no Vale do Silício, busquei referências em áreas em que eu 
precisava me desenvolver. Logo conheci o Joca e ele se tornou, 
além de uma fonte de conhecimento, um bom amigo. 


Como trabalho na ThoughtWorks e fui desenvolvedor durante 
muitos anos na minha carreira, eu já seguia pessoas técnicas com 
muita experiência. E, graças à minha longa história com agilidade, 
também tenho bons amigos e boas referências nessa área. Além 
disso, devido ao meu interesse com as Lean Inceptions, eu já 
acompanhava algumas autoridades na área de design e experiência 
do usuário. 


Mas ainda faltava a área de gestão e liderança de produtos digitais. 
A famosa intersecção entre tecnologia, negócio e experiência do 
usuário; uma área que cresceu neste século e vem se 


transformando rapidamente. Infelizmente, apesar desse 
crescimento, ainda há poucas referências sobre o assunto. 


Para a minha grata surpresa, uma das grandes autoridades 
mundiais estava bem aqui no Brasil, mais especificamente em São 
Paulo. Próximo a mim e ao alcance de todos os profissionais 
brasileiros — privilegiados que, assim como eu, falam português — 
que buscavam por conhecimento, fosse em livros, conferências ou 
blogs. 


r 


Liderar uma equipe de produto digital não é uma tarefa fácil. E 
essencial que você entenda conceitos, princípios e ferramentas. Ah, 
e também é importante você ter mais de vinte anos de experiência 
prática no assunto! 


Brincadeira, isso não é possível. Mesmo que já tenha idade para 
isso, você não consegue ter experiência prática em tudo. Eu, por 
exemplo, não consegui ter uma carreira como consultor, agilista, 
facilitador e, ao mesmo tempo, uma carreira como líder de produtos 
digitais. 


Mas é exatamente por isso que buscamos continuamente por 
conhecimento! É nessa trajetória que lemos livros, assistimos a 
vídeos, ouvimos podcasts e participamos de eventos e de 
treinamentos. Pelo caminho também buscamos trocar ideias e 
aprender com a experiência e vivência de outras pessoas, 
especialmente com aquelas que as compartilham com maestria. 


O Joca é uma dessas pessoas e sempre aprendi muito com ele. É 
por isso que eu considero uma grande felicidade e uma honra 
escrever o prefácio desta obra que eu já devorei e com a qual 
aprendi muito. 


Tenho certeza de que, assim como eu, você também vai encontrar o 
conhecimento que tanto busca nas páginas a seguir. 


Boa leitura, 


Paulo Caroli, autor de Lean Inception, Direto ao Ponto e outros livros 
para melhorar nossas organizações e ambientes de trabalho. 


Sobre o livro 


Qual é o papel de um(a) vice-presidente ou head de produto? Ser 
um head de produto engloba muitos aspectos e habilidades 
diferentes, e foi por isso que decidi escrever um livro inteiro sobre 
esse tópico. 


A arte e a ciéncia de liderar produtos digitais 


Embora eu esteja falando sobre desenvolvimento de produtos 
digitais, que é baseado em engenharia de software, normalmente 
considerada uma ciência, acredito que há uma parte da liderança de 
equipes de desenvolvimento de produtos que é mais arte do que 
ciência. Perguntando ao Google o que é arte, obtemos algumas 
respostas interessantes: 


"A expressão ou aplicação da habilidade e imaginação criativa 
humana, tipicamente em forma visual, como pintura ou 


escultura, produzindo obras a serem apreciadas principalmente 
por sua beleza ou poder emocional.” 





Para desenvolver um produto digital, precisamos de criatividade e 
imaginação para criar um produto que empodere seus usuários para 
fazerem algo. O empoderamento é o processo de tornar-se mais 
confiante e a confiança é uma emoção. E todo produto digital tem 
interfaces que podem ser admiradas. Portanto, é fácil ver o 
processo de criação de um produto digital como criação de uma 
obra de arte. 


"Uma habilidade para fazer uma coisa específica, tipicamente 


adquirida através da prática." 





Construir bons produtos digitais requer prática, muita prática. 


Por outro lado, ao perguntar ao Google o que é ciência, também 
obtemos respostas interessantes: 


"A atividade intelectual e prática que abrange o estudo 


sistemático da estrutura e comportamento do mundo físico e 
natural através da observação e do experimento”. 





Muitas equipes de desenvolvimento de produtos estão 
compartilhando suas experiências e criando e melhorando o 
conhecimento sobre como criar produtos digitais. 


"Um corpo de conhecimentos sistematicamente organizado 


sobre um assunto específico”. 





Estamos construindo esse conhecimento à medida que 
experimentamos novos processos e refinamos os existentes. O 
desenvolvimento de produtos digitais é uma ciência nova e está 
intimamente ligada à história do software. A primeira vez que um 
computador armazenou um software em memória e o executou com 
sucesso foi às 11 horas do dia 21 de junho de 1948, na 
Universidade de Manchester, no computador Manchester Baby. Foi 
escrito por Tom Kilburn e calculou o maior divisor inteiro do número 
2118 = 262.144. Começando com um grande divisor de teste, ele 
executou a divisão de 262.144 por esse grande divisor e depois 
verificou se o resto era zero. Caso não fosse, subtraía 1 do divisor 
de teste e repetia o processo até o resto ser zero. 


Ou seja, desenvolvimento de software e, consequentemente, gestão 
de produtos digitais são ciências com menos de 100 anos de vida. 
Se compararmos com medicina, construção civil, astronomia, 
matemática e outras ciências, estamos na primeira infância e ainda 
sabemos muito pouco. Temos investido muita energia na construção 
desse conhecimento para que as próximas gerações de 
desenvolvedores de produtos digitais sempre possam dar um passo 


à frente. É assim que todas as ciências são construídas, um passo 
de cada vez, cada geração começando a partir dos passos da 
geração anterior. 


Para quem é indicado e como o livro está 
organizado? 


O livro está focado na função de head de produto, mas será útil para 
qualquer pessoa da equipe de desenvolvimento de produtos digitais, 
bem como para quem não estiver nessa equipe, mas trabalha em 
uma empresa que possui ou planeja ter uma equipe de 
desenvolvimento de produtos. O conteúdo desse livro pretende 
ajudar a entender o que esperar da liderança desse time. O livro 
será dividido em três seções principais: 


e Conceitos: pessoas que me conhecem sabem que sou um 
grande fa de iniciar qualquer novo empreendimento com uma 
linguagem ubíqua (ubiquitous language), termo que Eric Evans 
usa no seu livro Domain-Driven Design para a prática de criar 
uma linguagem comum e rigorosa entre desenvolvedores e 
usuários - no meu caso, entre autor e leitores(as). Por esse 
motivo, começarei o livro definindo alguns conceitos, fazendo 
uma revisão de conceitos básicos como produto e gestão de 
produtos, e apresentando novos conceitos como funções e 
responsabilidades de head de produto, estrutura de equipe, 
carreira e carreira Y para gerentes de produto. 


e Princípios: toda empresa possui sua própria cultura e, dentro 
de cada empresa, todo departamento também possui sua 
própria cultura. Além disso, cada pessoa tem seus princípios e 
valores que norteiam seus passos pela vida. Aqui vou falar 
sobre a cultura, os valores e os princípios que acredito serem 
obrigatórios para criar produtos digitais de sucesso. E também, 
quais são os 4 principais valores que toda equipe de 


desenvolvimento de produtos e, consequentemente, toda 
empresa que tenha times de desenvolvimento de produtos 
digitais deve ter. 


e Ferramentas: aqui vou falar sobre as ferramentas que tenho 
usado nos meus quase 30 anos de carreira em liderança de 
desenvolvimento de produtos e tenho compartilhado com outros 
líderes para que eles ou elas possam usar com suas equipes. 
As ferramentas de que falarei incluem visão, estratégia, 
estrutura de equipe, métricas e cerimônias. 


Uma novidade neste livro em relação aos meus livros anteriores são 
as seções "Resumindo" no final de cada capítulo. Elas têm por 
objetivo ser um guia rápido sobre o conteúdo de cada capítulo para 
ajudar a revisá-lo rapidamente antes de seguir em frente. 


Outro ponto que gostaria de ressaltar é que o conteúdo deste livro é 
baseado em minha experiência prática em liderar desenvolvimento 
de produtos digitais. Ao longo de minha carreira venho 
experimentando diferentes formas de exercer essa liderança e o que 
estou descrevendo ao longo deste livro são os conceitos, princípios 
e ferramentas que melhor funcionaram, ou seja, que produziram os 
melhores resultados tanto para a empresa dona do produto, quanto 
para os usuários do produto, quanto para os times que trabalharam 
no desenvolvimento do produto. 


Certamente há outras formas de liderar desenvolvimento de 
produtos digitais que podem ser diferentes e até mesmo 
discordantes do que estou passando aqui. Contudo, na minha 
opinião, o fato de duas pessoas discordarem não significa 
necessariamente que uma delas está errada. Apenas que há formas 
diferentes de se ver e de se fazer as coisas. 


Antes de começar o livro, queria contar um pouco sobre minha 
história e minha experiência com liderança de produtos digitais. 


Quem é esse cara para falar sobre liderança de 
produtos digitais? 


Acho a sua pergunta bastante pertinente e apropriada; por isso, aqui 
vai um pequeno histórico. Acredito que minha experiência com 
gestão de produtos de software vem da época das primeiras linhas 
de código que escrevi, em meados da década de 1980. Desde 
aqueles primeiros programas de computador, eu já me preocupava 
com a facilidade de uso. 


Naquela época, elementos de interação como menus, janelas e 
mouse estavam começando a ficar populares com as primeiras 
versões do Microsoft Windows e do Mac OS. Isso me mostrou que 
software não era composto apenas de um conjunto de instruções 
para a máquina executar. Para fazer um bom software, era (e ainda 
é) preciso pensar em como esse software deve interagir com seus 
usuários e se ele atende aos objetivos de quem o desenvolveu. 


No final de 1992, quando estava terminando a faculdade de 
Engenharia da Computação no ITA, considerada por muitos como a 
melhor faculdade de engenharia do Brasil, um tio meu me falou que 
ele conheceu um negócio muito bacana de computadores chamado 
BBS (Bulletin Board System). Ele não entendia nada de 
computadores, mas disse que tinha algo a ver com redes e que, se 
eu achasse interessante, nós podíamos abrir um negócio juntos. 
Com mais dois sócios, meu tio e eu criamos a Dialdata BBS, que 
depois viria a ser um dos primeiros provedores de acesso à internet 
do Brasil, em 1995. 


Durante esses anos na Dialdata, escrevi muitas linhas de código, 
produtos digitais que eram disponibilizados para os usuários da BBS 
usarem. Também escrevi o sistema de cobrança, utilizado pelos 
funcionários da Dialdata, para fazer a cobrança dos clientes. A 
interação com usuários internos e externos me ensinou muito sobre 
desenvolvimento de produtos digitais. Não basta só ter uma ideia na 
cabeça e um computador na mão para sair criando o produto. É 


preciso entender o que o usuário espera do produto, e o que você e 
sua empresa planejam obter com ele. Desde essa época já tive o 
privilégio de ter pessoas me ajudando a escrever essas linhas de 
código, esses meus primeiros produtos digitais. 


Em 1998, a Dialdata foi vendida para uma empresa americana 
chamada VIA NETWORKS, que estava comprando provedores de 
serviços de internet em vários lugares do mundo para criar um 
provedor global de serviços de internet, para fazer um IPO (Initial 
Public Offering, ou oferta pública inicial de ações em uma bolsa de 
valores). Nessa época, fui convidado para trabalhar com gestão de 
produtos na VIA NET.WORKS. 


Foi a primeira vez em que tive contato com o termo e a função de 
gestão de produtos. Minha responsabilidade era criar um portfólio 
global de produtos a partir das diferentes ofertas de produtos das 
empresas que foram adquiridas pela VIA NET.WORKS em 10 
países da América Latina, EUA e Europa. Foi aí que comecei a 
entender a importância desse papel em empresas de tecnologia em 
geral e, especificamente, nas empresas de produtos digitais. 
Entendi quão desafiador é a liderança matricial, uma vez que eu 
tinha por missão criar esse portfólio global de produtos e, para fazer 
isso, não tinha ninguém em minha equipe e eu precisava contar com 
os times de produto locais, que tinham seus objetivos locais. 


Em 2005, Gilberto Mautner, que também estudou no ITA, me 
convidou para ajudá-lo a melhorar o processo de desenvolvimento 
de produtos na empresa dele, a Locaweb, líder no Brasil em 
hospedagem na web e aplicativos SaaS, como e-mail marketing e 
loja online. A Locaweb hospeda aproximadamente 25% de todos os 
dominios brasileiros. Quando saí da Locaweb em 2016, tínhamos 
um portfólio de mais de 30 produtos. O time completo de 
desenvolvimento de produtos — incluindo gestoras de produtos, 
designers de UX e engenheiras de software — contava com mais de 
100 pessoas. Aprendemos muito ao longo desses anos. Do waterfall 
para as metodologias e cultura ágeis, gestão de produtos, gestão 


participativa e varios outros conceitos foram experimentados como 
parte desse aprendizado. 


Em 2012, conheci o Vinicius Roveda, um dos fundadores e CEO da 
Conta Azul, quando a empresa ainda estava dando os seus 
primeiros passos. A ideia era Locaweb e Conta Azul terem algum 
tipo de parceria para oferecermos a solução de ERP da Conta Azul 
para os clientes da Locaweb. Na época a parceria não vingou mas 
Vinicius e eu conversamos algumas vezes sobre gestão e 
desenvolvimento de produtos, e desde essa época já era evidente a 
afinidade que tínhamos sobre esses temas. 


Ao longo de 2016, voltamos a conversar e começamos a explorar a 
possibilidade de eu me juntar ao time da Conta Azul. A empresa já 
tinha 5 anos e estava escalando a uma velocidade incrível. Por esse 
motivo, o Vinicius estava buscando pessoas que já tivessem 
passado por isso em outras empresas e pudessem ajudar o time da 
Conta Azul a escalar de forma sustentável, mantendo a alta 
velocidade de crescimento. Topei o desafio e fui para a Conta Azul 
para liderar um time de 60 pessoas que cresceu para 120 pessoas, 
sempre aprendendo muito! Conta Azul está localizada em Joinville, 
a maior cidade de Santa Catarina, um estado da região Sul do 
Brasil, então me mudei com minha família para morar lá. Digo que o 
que aprendi em 11,5 anos na Locaweb apliquei em 2 anos na Conta 
Azul. 


Em 2018, alguns problemas familiares trouxeram eu e minha família 
de volta para São Paulo. Comecei a contatar algumas empresas e 
percebi uma demanda muita alta por head de produto. Uma dessas 
empresas era o Gympass, um marketplace de três lados que 
conecta academias e estúdios a empresas e seus funcionários. No 
Gympass, liderei a equipe de desenvolvimento de produtos, 
juntamente com Rodrigo Rodrigues e Claudio Franco. Tivemos o 
desafio de criar um produto global usado por academias parceiras, 
empresas e seus funcionários em vários países. Como somos 
líderes nesta categoria, tivemos o desafio adicional de sermos os 
primeiros a enfrentar certos problemas, o que é bastante 


empolgante. Expandimos um time de 30 pessoas para um time de 
250 pessoas em 18 meses. Foi uma experiéncia incrivel. 


No segundo semestre de 2019, topei um novo desafio, o de criar 
não só um novo produto, mas uma nova unidade de negócios, o 
Gympass Wellness, onde conectávamos aplicativos de bem-estar 
(workout, nutrição, meditação, terapia online etc.) ao nosso 
marketplace para oferecer uma solução completa de bem-estar para 
nossos clientes e seus funcionários. O Gympass Wellness tornou-se 
peça chave em nossa estratégia durante a crise da COVID-19. 
Liderar o Gympass Wellness me deu a oportunidade de entender 
melhor o papel da gerência geral, ou seja, de ter a responsabilidade 
por todas as áreas do negócio, não só a parte de desenvolvimento 
de produtos digitais. 


Durante quase toda a minha carreira trabalhei com produtos digitais 
em empresas onde a tecnologia era o produto. A exceção ficou por 
conta do Gympass, onde o produto é um benefício corporativo de 
acesso a academias e estúdios, e o produto digital é uma 
ferramenta que ajuda na entrega desse produto principal. Mesmo 
assim, o Gympass sempre foi visto como uma startup de tecnologia. 
E, devido à crise da COVID-19, aceleramos a diversificação e 
digitalização de nosso portfólio de produtos: 


e Acesso a academias e estúdios: mais de 50.000 academias e 
estúdios em 14 países; 

e Aulas ao vivo: para quem gosta de treinar em grupo ou quer 
reviver o sentimento de classe com colegas de academia; 

e Personal trainers: para quem prefere uma abordagem mais 
personalizada e gosta de se exercitar no seu tempo; 

e Gympass Wellness: pacote de aplicativos com mais de 80 
apps para quem procura por opções para melhorar o bem-estar 
físico e mental (da nutrição à sessão de terapia). 


Foi uma experiência muito bacana poder ajudar uma empresa que 
não tinha tecnologia como seu core a poder inovar e se digitalizar, 
ou seja, criar produtos digitais para atingir seus objetivos 


estratégicos e para resolver problemas e atender necessidade de 
seus clientes e parceiros. 


Contudo, ainda estava faltando uma experiência na minha carreira. 
Sempre acreditei no poder da tecnologia para ajudar empresas a 
atingirem seus objetivos e ajudarem a servir ainda melhor seus 
clientes, mas nunca tive a oportunidade de trabalhar em uma 
empresa tradicional e ajudá-la a criar e implementar uma estratégia 
digital. Tenho acompanhado casos famosos de transformação digital 
como o do Banco Itaú e da Magazine Luiza até que, no segundo 
semestre de 2020 recebi e aceitei o convite para liderar a estratégia 
digital da maior imobiliária do país, a Lopes Consultoria de Imóveis, 
com um time de mais de 100 pessoas, onde lidero não só o 
desenvolvimento de produtos digitais como também marketing e 
vendas digitais, me proporcionando mais uma experiência de gestão 
geral e de muito aprendizado! 


Qual é o seu propósito? 


Li um livro intitulado Como avaliar sua vida (How will you measure 
your life?), do Prof. Clayton Christensen, professor de Harvard e 
criador do conceito "inovação disruptiva". Nesse livro, publicado em 
2012, ele conta como percebeu que ao longo dos anos seus colegas 
de turma acabaram se tornando pessoas infelizes, com suas vidas 
pessoais e profissionais distantes da que haviam planejado na 
época da faculdade. Alguns tinham seus nomes atrelados a 
escândalos financeiros e fiscais. Outros se casaram, separaram e 
brigam judicialmente com os ex-cônjuges. Outros ainda mal 
conseguem acompanhar o crescimento dos filhos. 


Essa constatação o fez refletir sobre como seria possível aumentar 
as chances de encontrar satisfação e felicidade ao longo da vida. No 
livro, ele propõe que uma forma de se fazer isso é aplicando 
algumas das ferramentas do mundo da administração de empresas 
a gestão da vida pessoal e profissional. 


Uma dessas ferramentas é o propósito. O propósito empresarial é o 
motivo de existir de uma determinada empresa. Muitas publicam 
esse motivo de forma clara. O Google tem por propósito organizar 
toda a informação do mundo, e fazê-la universalmente acessível e 
util. A Nike quer trazer inspiração e inovação para todos os atletas 
do mundo, e que se você tem um corpo, você também é um atleta. 
Na Conta Azul impulsionamos o sucesso do pequeno 
empreendedor, e no Gympass, combatemos o sedentarismo. 


Prof. Christensen propõe que as pessoas também tenham um 
propósito que deve nortear suas decisões ao longo da vida, da 
mesma forma que as empresas devem ter um propósito que norteie 
as suas. Achei essa ideia bem interessante e me provocou a pensar 
no meu propósito que, após analisar como invisto meu tempo e no 
que tenho prazer e satisfação em trabalhar, acabei definindo como 
sendo: 


MEU PROP SITO 


Ajudar as pessoas a criarem produtos digitais melhores. 





Por isso, compartilharei nas próximas páginas o que aprendi ao 
longo desses quase 30 anos de experiência. Acredito que o que vou 
compartilhar poderá ajudar na criação de produtos digitais melhores, 
que atingirão os objetivos do dono do produto, ao mesmo tempo em 
que atenderão às necessidades dos seus usuários. 


Sei que ainda tenho muito a aprender e quero continuar aprendendo 
sempre. Como o aprendizado vem da troca de experiências e da 
conversa, convido-o a compartilhar suas experiências lá no meu 
perfil do LinkedIn (https://www.linkedin.com/in/jocatorres) ou via e- 
mail (jtorres@jig.com.br). 


Vamos começar? 
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Conceitos 


Pessoas que me conhecem sabem que sou um grande fa de iniciar 
qualquer novo empreendimento com uma linguagem ubiqua 
(ubiquitous language), termo que Eric Evans usa no seu livro 
Domain-Driven Design para a pratica de criar uma linguagem 
comum e rigorosa entre desenvolvedores e usuários - no meu caso, 
entre autor e leitores(as). 


Por esse motivo, começarei o livro definindo alguns conceitos, 
fazendo uma revisão de conceitos básicos como produto e gestão 
de produtos, e apresentando novos conceitos como funções e 
responsabilidades de head de produto, estrutura de equipe, carreira 
e carreira Y para gerentes de produto. 


CAPÍTULO 1 
O que é produto digital e gestão de produtos? 


Neste capítulo farei uma revisão de alguns conceitos básicos de 
gestão de produtos que serão necessários para os próximos 
capítulos, onde definirei conceitos mais ligados à liderança de 
desenvolvimento de produtos. 


Vamos começar do começo: 


PRODUTO DIGITAL 


Produto digital é qualquer software que tenha usuários. 





Uma forma comum de classificar os produtos digitais é pelo tipo de 
público a que ele atende. Existem os produtos para consumidor final 
(Netflix, Spotify etc.) conhecidos como B2C (business to consumer), 
para empresas (Locaweb, Conta Azul, SAP etc.) conhecidos como 
B2B (business to business) e os mistos, que atendem tanto a 


consumidores finais quanto empresas (Instagram, Mercado Livre 
etc.). 


Outra forma de se classificar um produto digital é olhando para a 
forma como o produto é entregue aos usuários (como online, não 
online e embarcado), ou de acordo com o que ele faz: e-mail, 
comércio eletrônico, pagamento, e-mail marketing, gestão de 
conteúdo, educação, comunicação, colaboração, relatório, 
entretenimento, sistema operacional, ERP, CRM etc. 


Essas diferentes formas de se classificar não são excludentes. Por 
exemplo, a Netflix é um produto digital para o usuário final, mas 
também é um produto online de entretenimento. 


1.1 Digital ou tradicional? 


Além de entender o que é um produto digital e como classificá-lo, 
precisamos também entender a natureza da empresa dona desse 
produto digital. 


Digital: o produto vendido pela empresa é o software ou a 
tecnologia desenvolvida pelo time de desenvolvimento de produto. 
Gestão de Produtos é o core da empresa, responsável pela visão de 
futuro e pela estratégia da empresa. O head de produto terá um 
papel central na definição e execução da estratégia da empresa. 
Exemplos: Locaweb, Conta Azul, Zendesk, Instagram. 


Tradicional: o produto vendido pela empresa existiu, provavelmente 
durante muitos anos, sem a tecnologia, mas a empresa começa a 
entender como tecnologia pode potencializar o produto. Gestão de 
Produtos é um enabler, ou seja, algo que possibilita e potencializa o 
negócio principal, mas não é o core. É vista como a "área de digital". 
O head de produtos terá que ganhar o seu espaço, mostrando os 
benefícios que a tecnologia pode trazer. Exemplos: Itaú, Magazine 
Luiza, Lopes. 


Tradicional nascida digital: o produto vendido pela empresa 
poderia existir sem a tecnologia, mas a tecnologia potencializa muito 
o produto. Gestão de Produtos é também um enabler, mas não é o 
core. O head de produto terá um papel muito importante para a 
definição e execução da estratégia da empresa, mas não será 
central. Exemplos: Nubank, Netflix, Airbnb, Uber, Gympass. 


1.2 Plataformas 


As plataformas são produtos que entregam mais valor quanto mais 
usuários utilizam a plataforma. É o famoso efeito de rede, baseado 
na quantidade de interações possíveis entre esses usuários, 
quantidade essa regida pela fórmula n n- / , onde n é o número 
de usuários. Plataformas existem há muitos anos no mundo offline. 
Um bom exemplo são os mercados da antiguidade. Eles são uma 
plataforma de dois lados, com compradores de um lado e 
vendedores do outro. Quanto mais vendedores tiver, mais útil é o 
mercado para os compradores. E quanto mais compradores tiver, 
mais atraente será o mercado para os vendedores. 





Figura 1.1: Mercado antigo com compradores e vendedores (Copper Market, Cairo de 
Edward Angelo Goodall, 1871 - 
https://en.wikipedia.org/wiki/Bazaar#/media/File:Edward_Angelo_Goodall_Copper_market_ 
Cairo_1871.jpg) 


Existem plataformas de um unico lado (Facebook, Instagram, 
WhatsApp etc.) e plataformas de multiplos lados, que podem ser de 
3 tipos: 


Troca: com compradores de um lado e vendedores do outro lado. 
Nesse tipo de plataforma, é comum uma pessoa entrar pelo lado 
comprador e ser convidado a participar do lado vendedor. Quem 
nunca foi convidado a dirigir para o Uber? Exemplos, além do Uber, 
são Airbnb, Mercado Livre etc. As plataformas de troca são também 
conhecidas como marketplaces. 


Conteúdo: reúne produtores e consumidores de conteúdo com 
anunciantes. O conteúdo é o foco e a monetização é feita 
normalmente por meio de veiculação de anúncios. Exemplos são o 
Facebook, o Google e portais de notícia. 


Técnicas: funcionam como um sistema operacional onde, de um 
lado, ha os especialistas e, do outro, os usuários. O Android e o iOS 
são bons exemplos, com os desenvolvedores de apps de um lado e 
os usuários do outro. A Conta Azul é outro exemplo, de um lado 
estão os donos de pequenos negócios e do outro, os contadores. 


Nas plataformas costuma-se desenvolver um produto para cada 
participante da plataforma, mais um ou mais produtos que cuidam 
da interação entre esses participantes. 


1.3 Gestão de produtos digitais 


Já vimos a definição de produto digital, a importância de entender se 
a empresa dona do produto é uma empresa digital, tradicional ou 
tradicional nascida digital e entendemos o que são plataformas. 
Agora vamos entender o que é gestão de produtos. 


GESTÃO DE PRODUTOS 


Gestão de produtos digitais é a função responsável por todos 
os aspectos de um produto de software, durante todo o ciclo 
de vida desse produto, desde a sua concepção até o fim de 
sua vida. 


É a função responsável por fazer a conexão entre a estratégia 
da empresa e os problemas e necessidades dos clientes por 
meio do produto digital. Esta pessoa deve, ao mesmo tempo, 
ajudar a empresa a atingir seus objetivos estratégicos, enquanto 
soluciona os problemas e atende às necessidades dos clientes. 





Para saber mais 


Pronto, já vimos, de forma bem resumida os principais conceitos de 
gestão de produtos digitais e estamos prontos para entender mais 


sobre como liderar produtos digitais. 


Caso vocé queira saber mais sobre os conceitos que apresentei 
acima, vocé pode ler meu livro Gestao de produtos: Como aumentar 
as chances de sucesso do seu software. Nele, falo em detalhes 
sobre esses e outros conceitos relacionados a gestao de produtos 
digitais, bem como sobre ciclo de vida de um produto de software, 
relacionamento do gestor de produtos com as outras areas e 
funções da empresa, gestão de portfólio de produtos e sobre onde 
usar gestão de produtos de software. 


1.4 Resumindo 


e Produto digital é qualquer software que tenha usuarios. 


e Produtos digitais podem existir tanto em empresas digitais, em 
que o produto digital é o produto que a empresa vende, quanto 
em empresas tradicionais, que usam o produto digital para 
alavancar e potencializar o produto principal da empresa. 


e Recentemente começaram a surgir as empresas tradicionais 
nascidas digitais, ou seja, empresas que vendem um produto 
não digital, mas que têm o produto digital como parte crítica de 
sua estratégia desde o início da empresa. 


e Plataformas são produtos que entregam mais valor quanto 
mais usuários utilizam a plataforma, o famoso efeito de rede. 
Existem plataforma de um único lado e plataformas de múltiplos 
lados, que podem ser de troca, de conteúdo ou técnicas. 


e Gestão de produtos é a função responsável por conectar os 
objetivos estratégicos da empresa com os problemas e 
necessidades dos clientes. 


No próximo capitulo vamos ver o papel e as responsabilidades de 
um(a) head de produto e entender um pouco sobre um conceito 
muito importante, o de senioridade. 


CAPITULO 2 
Papéis, responsabilidades e senioridade 


No capitulo anterior acabamos de rever alguns conceitos basicos de 
produtos digitais. Agora vamos entender o que é ser head de 
produto, quais os seus papéis e suas responsabilidades. 


2.1 Gerenciamento de expectativas 


Qualquer que seja o caminho que o leve à possibilidade de ocupar 
um cargo de liderança de produto, seja por considerar esse o seu 
próximo passo na carreira ou por ter a tarefa de encontrar alguém 
para ocupar esse cargo, é importante esclarecer qual é a principal 
responsabilidade deste papel: gerenciamento de expectativas. 
Será algo entre 50 a 80% do seu tempo. 


Ouço de alguns gestores de produto que querem se tornar head de 
produto porque veem essa posição como uma grande oportunidade 
de ter uma opinião forte sobre, ou até mesmo de liderar, a 
construção da visão e estratégia do produto e, consequentemente, 
da empresa, especialmente se você estiver em uma empresa que é 
puramente digital ou tradicional nascida digital. 


Isso realmente acontece, e é parte de sua responsabilidade, mas 
devo dizer que isso não representa mais de 10% do trabalho de 
head de produto. E mesmo esses 10% não são um empreendimento 
solo. Você precisará construir a visão e estratégia de produto em 
colaboração com as principais partes interessadas em seu produto, 
especialmente os fundadores da empresa, que são os primeiros 
gestores de produto de qualquer empresa e a diretoria, os C-level. 


Os outros 90% da responsabilidade do head de produto são 
compartilhados entre ajudar gestores de produto em seu 


desenvolvimento - algo entre 10% a 40%, dependendo da 
senioridade desses gestores de produto - e o gerenciamento de 
expectativas, que vai tomar de 50% a 80% do seu tempo. 


Por gerenciamento de expectativas, quero dizer gerenciar a 
ansiedade de todos os interessados no produto, internos e externos, 
em saber quando e como o produto vai ter essa ou aquela 
funcionalidade para trazer aquele resultado para atingir aquele 
objetivo. 


É importante ter essa divisão de tarefas e responsabilidades clara 
antes de decidir aceitar a função de head de produto, para entender 
o que outras áreas e sua equipe vão esperar de você, caso você 
decida aceitar o trabalho. 


Normalmente, tenho visto pessoas preenchendo uma posição de 
head de produto vindo com três históricos principais: ou é uma 
gestora de produto que começará a gerenciar outros gestores de 
produto ou é uma pessoa que lidera design ou marketing ou é uma 
pessoa que lidera engenharia. 


Gerente de produto preenchendo a posição de head de produto 


Esse pode ser um passo natural na carreira de uma gestora de 
produto. À medida que se torna mais experiente, ela pode se tornar 
a pessoa preferida de outros PMs em busca de conselhos. Portanto, 
os 10% a 40% de ajudar outros gerentes de produto a fazer parte da 
posição de chefe de produto podem vir naturalmente para ela. No 
entanto, ainda há 10% da construção da visão e 50% a 80% do 
gerenciamento de expectativas a serem considerados. 


A construção da visão também não deve ser algo novo para um 
gestor de produto sênior. Ele já deve fazer isso para o produto ou 
parte do produto que cuida, portanto não deve ser novidade, apenas 
ter um escopo maior. Lembre-se de trabalhar na construção de uma 
visão de alto nível e dar espaço para que os detalhes sejam 
trabalhados pelos PMs que o head de produto lidera. Construir 


esses detalhes de uma visão de produto é uma responsabilidade e 
oportunidade desenvolvimento importante para gestores de produto. 


Os 50% a 80% restantes do tempo gasto no gerenciamento de 
expectativas também não devem ser estranhos ao gestor de produto 
que aspira a se tornar head de produto. Na verdade, ele já faz isso 
com o produto ou parte do produto de que cuida. Desde os 
membros de sua equipe, as pessoas de outras áreas, os C-level, até 
o fundador da empresa. Aqui, novamente, estamos falando de um 
aumento de escopo. E, novamente, precisamos permitir que os PMs 
liderados pelo head de produto também gerenciem a ansiedade das 
partes interessadas, para que possam desenvolver essa habilidade. 
Mas não se esqueça de que, como head de produto, você será o 
responsável para gerenciar as expectativas do C-level, dos 
fundadores e do conselho. 


Se você não deseja gerenciar outras pessoas, tudo bem. Sempre é 
possível ter espaço em sua equipe para uma posição de gerente de 
produto mais sênior. Algumas empresas chamam isso de principal 
product manager. Falarei mais sobre esse papel ao longo do livro. 


O primeiro passo para um gestor de produto se tornar head de 
produto é quando continua trabalhando com sua própria equipe 
(engenheiros e designers de produto) e supervisiona o trabalho de 
um gestor de produto em outra equipe. Um nome possível para essa 
nova posição é group product manager (GPM), pois ela está 
gerenciando um grupo de produtos ou um grupo de partes de um 
produto. Indo tudo bem, o próximo passo é contratar seu substituto 
para a função existente que ele ainda desempenha como gestor de 
produto. Livre de seu trabalho diário de gerenciar um produto, ele 
poderá gerenciar dois ou mais gestores de produto. 


Líder de UX ou líder de marketing 


UX e marketing são duas áreas muito próximas à gestão de 
produtos. Enquanto o UX trabalha em conjunto com gestão de 
produtos em atividades de discovery, o marketing trabalha em 


conjunto com gestao de produtos em atividades para contar ao 
mundo sobre o produto e o problema que ele resolve e para 
aumentar sua base de usuarios. Ou seja, ambos entendem bem o 
trabalho de gestao de produtos por trabalharem diariamente com 
isso. 


Tanto para um lider de UX quanto para um lider de marketing que 
assume essa posição de head, é importante que essa pessoa 
entenda não apenas as semelhanças, mas também as diferenças 
entre as duas funções e seu papel e responsabilidades no sucesso 
do produto. 


CTO / Head de Engenharia 


Se você é um CTO ou um líder de engenharia e foi convidado para 
liderar a área de produto, é provável que você tenha sido solicitado 
a preencher essa posição em adição das suas responsabilidades 
existentes em engenharia. Existem prós e contras em combinar os 
dois papéis. Como ponto positivo, desenvolvimento de produto é 
uma área só que tem por objetivo entregar o melhor produto para 
atingir os objetivos da empresa enquanto resolve problemas dos 
usuários. Ter uma única pessoa liderando a área facilita o 
alinhamento do time. 


Por outro lado, especialmente com time maiores, juntar esses dois 
papéis pode gerar uma sobrecarga considerável na sua agenda e 
no dia a dia de trabalho. É importante conseguir priorizar e ter boas 
pessoas no time para você delegar algumas de suas tarefas. 


Tanto na Locaweb quanto na Conta Azul eu tive esse papel de 
liderar todo o time de desenvolvimento de produto, ou seja, gestores 
de produto, product designers e engenharia. Apesar de ter 
background técnico, eu sempre tive pessoas seniores para me 
ajudar na gestão de engenharia assim como na gestão de design e 
de produtos. Já no Gympass rodamos durante 18 meses com um 
CTO, um head de produtos para consumers e eu como head de 
produtos para empresas e parceiros. 


2.2 Papeis e responsabilidades 


Como eu comentei acima, o papel do head de produto está dividido 
em 3 grandes areas: 


Visao e estratégia de produto: normalmente toma algo em torno 
de 10% do tempo de um head de produto. Definir a visao de produto 
é definir como sera o produto no futuro. O que você quer que o 
produto seja quando ele crescer? E a estratégia é o caminho para 
chegar até a visão. Construir visão e estratégia de produto é um 
trabalho que o head de produto faz alinhado com os fundadores da 
empresa, a alta gestão e o conselho, com input de todas as áreas 
da empresa e do cliente. Vou falar mais sobre construção de visão e 
estratégia nos próximos capítulos. 


Ajudar gestores de produto em seu desenvolvimento: a 
depender da senioridade do seu time, isso vai tomar algo em torno 
de 10% a 40%. Quanto mais júnior e inexperiente, mais tempo você 
terá que dedicar para o desenvolvimento do seu time. Falarei mais à 
frente sobre algumas das Ferramentas importantes: reuniões 1:1, 
reuniões de time, avaliação e feedback, product council, product 
update e organização de time. 


Gestão de expectativas: pelo menos metade do seu tempo será 
dedicado à gestão de expectativas, podendo chegar a até 80%. Na 
área de produtos e, principalmente, na liderança de produtos 
digitais, não existe "comunicação em excesso". Sempre haverá 
alguém que tem expectativas sobre o produto e que ainda não está 
ciente da sua visão e estratégia. Com muitas empresas com quem 
converso sobre produtos digitais ouço uma reclamação bastante 
comum, de que a área de desenvolvimento de produtos é uma caixa 
preta. E isso gera muita expectativa das outras áreas, que precisam 
que suas dores de produto sejam resolvidas. Por outro lado, o time 
de desenvolvimento de produto também tem expectativas, quer 
saber qual a visão de produto, qual a estratégia, qual o roadmap, 
quais as prioridades. A melhor maneira de gerir essas expectativas 


é por meio de comunicação. Como comentado, as Ferramentas que 
serão apresentadas mais à frente serão muito úteis para a gestão 
de expectativas. 


Pessoas que querem crescer na carreira para serem head de 
produto costumam justificar essa progressão de carreira motivados 
pelo desejo de poder ter uma voz mais ativa e até mesmo guiar a 
definição de visão e estratégia do produto. Sinto frustrá-los. Como já 
mencionei, isso é apenas 10% do trabalho de um head de produto. 
Os outros 90% do tempo de um head de produtos são dedicados ao 
trabalho de ajudar os gestores de produto a se desenvolverem e à 
gestão de expectativas. Reforço que, quanto mais júnior e 
inexperiente for o seu time, mais tempo você terá que dedicar para o 
desenvolvimento do seu time, o que pode tomar até 40% do seu 
tempo. Por outro lado, se seu time for júnior e inexperiente, mais 
trabalho você terá com gestão de expectativas, que pode chegar a 
tomar até 80% do seu tempo. 


Imagine que você tem um time júnior e inexperiente, que tome 30% 
do seu tempo, e que, em função disso, você tenha muita gestão de 
expectativa para fazer, tipo 70% do seu tempo. Ou seja, 100% do 
seu tempo será tomado com ajudar seu time a se desenvolver e em 
gerir expectativas. Por isso, é importante você tomar muito cuidado 
com a senioridade do seu time, caso contrário não sobrará tempo no 
seu dia a dia para cuidar da visão e estratégia do produto que você 
lidera. 


Certa vez, ao explicar essa divisão de tempo, recebi a pergunta se 
gestão de resultados não seria também uma das responsabilidades 
do head de produto. Sim, é uma das suas responsabilidades, e cai 
na categoria de gestão de expectativas. Todos na empresa esperam 
que o produto ajude no atingimento das metas e nos resultados da 
empresa. Assim como os usuários do produto também têm a 
expectativa de atingir suas metas e resultados utilizando o seu 
produto. Então, uma forma de gerir as expectativas das pessoas da 
empresa e de seus usuários é ajudando-os a atingir seus resultados 
e deixando claro como o produto está tornando isso possível. 


2.3 Niveis de senioridade 


Este é um tópico que ouvimos quase diariamente em todas as 
empresas: níveis de senioridade. Existem muitas situações em que 
esse assunto surge, como em contratação, avaliação de 
desempenho, aumentos, promoções, bônus etc. Quanto mais sênior 
é uma pessoa, mais você espera dela. Afinal, ela tem experiência e 
conhecimento para lidar com as situações mais difíceis do trabalho. 
Minha experiência me mostrou que precisamos analisar a 
senioridade de uma pessoa com base em três dimensões: 


Tempo 


Normalmente avaliamos a senioridade com base no tempo. Por 
exemplo, se uma pessoa tem mais de 10 anos de experiência, ela é 
sênior. No entanto, o tempo sozinho não é suficiente. Se ela fez a 
mesma coisa nesses 10 anos, sem se questionar e sem 
continuamente buscar melhorar e experimentar coisas novas, ela 
não evoluiu como profissional. Ela não colocou novas ferramentas 
em seu cinto de utilidades. E terá bastante dificuldade ao enfrentar 
novas situações uma vez que não tem as ferramentas necessárias. 


Conhecimento 


Portanto, além do tempo, também devemos considerar o 
conhecimento. Podemos traduzir o conhecimento como o conjunto 
de ferramentas que um profissional possui em seu cinto de 
utilidades. Se uma pessoa conhece apenas uma ferramenta, ela a 
usará para resolver todos os problemas. É como diz a lei do martelo: 
para um martelo, tudo parece um prego. Essa lei é atribuída a 
Abraham Maslow, psicólogo americano bastante conhecido pelo 
conceito da pirâmide de hierarquia de necessidades. 


Quanto mais ferramentas alguém tiver, mais fácil será enfrentar 
novas situações e encontrar soluções. Essa é a razão pela qual os 
consultores são tão versáteis. Eles trabalham por curtos períodos de 


tempo em clientes diferentes, enfrentando problemas diferentes e 
precisam criar maneiras de resolver novos problemas, ja que cada 
novo cliente em que trabalha tem problemas e contextos diferentes. 


As vezes, uma consultora com 3 anos de experiéncia, trabalhando 
em 6 clientes diferentes, tera muito mais ferramentas em seu cinto 
de ferramentas do que alguém que permaneceu na mesma empresa 
por 10 anos. A consultora provavelmente sera mais sênior do que a 
pessoa que ficou por 10 anos na mesma empresa, fazendo o 
mesmo trabalho e resolvendo os mesmos problemas sem se 
questionar e buscando continuamente melhorar, melhorar e 
experimentar coisas novas. 


Para avaliar a antiguidade de alguém - inclusive quando estamos 
autoavaliando nossa propria senioridade - precisamos olhar para 
anos de experiéncia e a qualidade do conhecimento acumulado 
durante esses anos. Contudo, isso nao é suficiente. 


Comportamento 


O comportamento é uma dimensão da senioridade que 
normalmente não é discutida quando avaliamos a senioridade de 
alguém, mas é tão importante quanto tempo e conhecimento. Às 
vezes tenho a impressão de que é ainda mais importante que tempo 
e conhecimento. 


A senioridade comportamental significa que a pessoa sabe como se 
comportar adequadamente: 


e Ser ético, ser uma pessoa integra e com a intenção correta; 

e ter alinhamento com os valores e a cultura da empresa; 

e ter alinhamento e comprometimento com o propósito da 
empresa; 

e ter alinhamento e comprometimento com os objetivos 
estratégicos da empresa. 


Vou dar alguns exemplos e contraexemplos de senioridade 
comportamental para tornar o conceito mais claro: 


e Metas: todas as empresas têm metas. Todas as empresas têm 
objetivos quantificados e metas são definidas para ajudar a 
atingir esses objetivos. Um método muito conhecido para definir 
objetivos e quantificar os resultados é o OKR (Objective and 
Key Results ou objetivos e resultados chaves). Algumas 
empresas ainda usam essas metas para definir a remuneração 
variável de seus funcionários, também conhecida como política 
de bônus. Invariavelmente, depois que os objetivos são 
definidos, as coisas mudam. E mesmo quando tudo estiver 
estável, pode ser necessário fazer um trabalho não relacionado 
aos objetivos. Alguém com senioridade comportamental 
entende que as coisas mudam e que seu trabalho não se limita 
as metas previamente acordadas e fará o que for necessário. 
Alguém sem senioridade comportamental dirá que ela não pode 
mudar ou fazer qualquer outra coisa além do que é definido 
como sua meta. 


e Reclamar: como todos sabemos, às vezes as coisas não 
andam como esperamos. É assim que a vida é. E sempre há 
pessoas que reclamam. E a culpa é sempre de outra pessoa e 
sempre há muitas desculpas para explicar por que as coisas 
não aconteceram como esperamos. Reclamar sem fazer nada 
para ajudar a resolver a situação é um comportamento típico de 
alguém que não tem senioridade comportamental. Uma pessoa 
sênior, quando enfrenta problemas, tenta entender o que 
aconteceu, sem procurar culpados. Procura uma solução para 
os problemas e procura entender como evitar que esses 
problemas ocorram novamente. 


Acredito que com esses dois exemplos e contraexemplos fica mais 
claro o que significa senioridade comportamental. 


Na minha opinião, esta é a dimensão mais importante de 
senioridade. Se você tem alguém com senioridade em 
conhecimento e muitos anos de experiência, mas sem senioridade 
comportamental, ela não só terá maiores chances de ter um 


desempenho ruim, como também interferirá no desempenho de sua 
equipe. 


Qual a sua senioridade? 


Portanto, da próxima vez que você estiver avaliando o nível de 
senioridade de alguém — inclusive quando estiver avaliando sua 
própria senioridade —, avalie anos de experiência, qualidade do 
conhecimento acumulado durante esses anos e a senioridade 
comportamental. Somente então você poderá avaliar 
completamente o nível de senioridade dessa pessoa. 


2.4 Resumindo 


e O head de produto é responsável por coordenar a definição da 
visão e estratégia de produto, por ajudar os gestores de 
produto em seu desenvolvimento e por gerir as 
expectativas de todas as pessoas que têm interesse em seu 
produto. 


e Um conceito muito importante para ajudar uma head de produto 
com suas responsabilidades é o conceito de senioridade, que 
tem 3 dimensões, duas bem conhecidas, o tempo e o 
conhecimento e uma terceira não tão conhecida, mas tão 
importante quanto às outras, a senioridade de comportamento. 


No próximo capítulo vamos entender um pouco mais sobre a 
carreira de produtos. 


CAPITULO 3 
Carreira de gestao de produtos 


A progressão de carreira de gestão de produtos pode ser vista 
iniciando com o Business Analyst (BA), tendo por responsabilidade 
a especificação do que o time de desenvolvimento de produto vai 
construir, avançando para Product Owner (PO), que além de 
especificar deve priorizar o que o time deve fazer, e chegando ao 
topo da carreira com o Product Manager (PM), que, além de 
especificar e priorizar, deve definir a visão e estratégia do produto 
ou pedaço de produto de que ele cuida. 


Visão e 
estratégia 


Especificação | Priorização 





Figura 3.1: BA, PO e PM 


Uma outra forma que muitas empresas têm adotado para enxergar 
essa evolução de carreira é considerar as fases de BA e PO como 
Associate Product Manager (APM), com a responsabilidade de 
especificar e priorizar. É o primeiro passo na carreira de gestão de 
produtos. 
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Figura 3.2: APM e PM 


Como gestão de produtos é um papel de grande responsabilidade, 
recomendo que as pessoas que ingressem na carreira de produtos 
tenham alguma experiência prévia em outras áreas, tais como 
engenharia, design e marketing. 


Ja vi também ótimos gestores de produto vindos de operações, 
suporte, gestão de projetos, financeiro, e até mesmo jurídico. Ao 
longo da minha carreira tenho notado que pessoas que acabaram 
de sair da faculdade não têm a bagagem necessária para conseguir 
ser bons gestores de produto. É importante ter esse conhecimento 
em outras áreas até mesmo para ajudar a entender como seu 
produto impacta essas outras áreas. 


E depois? 


A pergunta que fica é: o que vem depois? De APM para PM, que 
pode chegar a PM sênior, mas qual é o próximo passo da carreira 
de gestão de produtos? 


Um time mínimo de desenvolvimento de produtos é composto por 
alguns engenheiros. Normalmente começa com 2, podendo chegar 
a até 7 engenheiros, sendo um deles alguém mais sênior, com um 
papel de tech lead, mais um product designer (PD) e um product 
manager (PM). Quando há a necessidade de criar um segundo time 
para cuidar de uma outra parte do produto, há duas formas de fazer 
essa expansão: 


e Expandir engenheiros, dividir e contratar PM e PD: podemos 
dividir o time de engenheiros em 2 times, cada um com um 
foco, e manter temporariamente o product manager e o product 
designer nesses dois times até conseguirmos contratar um 
segundo product manager e um segundo product designer. 
Esse modelo é usado quando se tem muita clareza do escopo 
de trabalho do segundo time. 


e Contratar PM e PD para fazer discovery, expandir 
engenheiros e dividir: nesse caso trazemos primeiro um PM e 
um PD adicional para trabalhar no discovery do que se quer 
fazer com esse segundo time. Enquanto isso, continua-se 
contratando mais engenheiros para expandir o primeiro time. 
Em um determinado ponto do discovery, já tendo alguma 
clareza do que esse segundo time vai fazer, aí sim fazer a 


divisao de time. Esse modelo pode ser util quando ainda nao ha 
clareza do que esse segundo time vai trabalhar e é preciso 
fazer um trabalho de discovery que não cabe no dia a dia do 
PM e do PD originais. 
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Figura 3.3: Duas formas de criar um segundo time 


Em ambos os casos, se a PM original for mais sénior, podemos 
contratar para essa posição de segundo PM alguém mais junior ou 
até mesmo um associate product manager e dar à PM mais sênior a 
oportunidade de ajudar o mais júnior a se desenvolver. Seria uma 
primeira oportunidade de gestão de pessoas para essa PM sênior, 
se isso for algo que ela está buscando para a sua carreira. 
Enquanto ela ainda cuida de um produto ou pedaço de produto com 
o primeiro time, ela pode começar a experimentar na prática como é 
liderar um outro PM júnior. 


Depois de um a dois trimestres rodando nessa configuração é 
possível entender se a PM mais sênior gostou desse novo papel, de 
ajudar um PM mais júnior a se desenvolver. Se esse papel for algo 
que faça sentido para a PM sênior, é possível pensar em colocar 


mais PMs para ela ajudar. Nesse ponto vai ficar cada vez mais dificil 
para essa PM sênior gerenciar um produto ou um pedaço de um 
produto. 


Estou focando na carreira de PM, mas existe um caminho similar 
tanto em engenharia quanto em product design. O tech lead mais 
sênior pode vir a liderar o tech lead do outro time, assim como o 
product designer mais sênior pode liderar o product designer do 
outro time. 


3.1 Group Product Manager 


Esse é o momento em que o PM sênior se torna um Group Product 
Manager (GPM). Esse é o primeiro passo em uma carreira de head 
de produto, quando o product manager não cuida diretamente de 
um produto ou de um pedaço de um produto e tem a 
responsabilidade de ajudar outros PMs a se desenvolverem e a 
gerenciarem seus produtos. Normalmente isso acontece quando a 
pessoa está liderando 3 ou mais product managers e é responsável 
por um conjunto de funcionalidades ou mesmo um produto inteiro. 
Em algumas empresas essa posição é chamada de head de 
produto, ou diretor de produto ou até mesmo de vice-presidente de 
produto. 


Na Conta Azul, tínhamos GPMs que cuidavam de pedaços do 
produto. Um GPM ficava mais focado nas funcionalidades 
financeiras do produto tais como relatório financeiro, emissão de 
boleto etc. enquanto ou outro tinha foco maior em funcionalidades 
contábeis e fiscais tais como registro de compra e venda, gestão de 
estoque, emissão de notas fiscais etc. 


No Gympass, tínhamos diretores de produto focados em cada ator 
de nosso marketplace. Um diretor de produto focado nas 


academias, outro focado no RH de nossos clientes e um terceiro 
focado nos funcionarios de nossos clientes. 


Em uma empresa pequena, o GPM pode ser o nível mais alto de 
carreira de produtos. Por exemplo, em uma empresa com até uns 6 
ou 7 PMs, um único GPM para coordenar esses PM pode ser 
suficiente. Quando passa desse número, pode ser interessante ter 
um segundo GPM, ou mesmo um CPO ou VP de produto que lidera 
o GPM e alguns PMs. 


Além de liderar PMs, o GPM também tem o papel de coordenar a 
definição da visão e da estratégia de um grupo de produtos ou de 
funcionalidades. Por exemplo, o diretor de produtos para RH no 
Gympass tem que liderar os PMs que trabalham em pedaços do 
produto para os RHs, que chamávamos de Portal do RH, bem como 
em definir a visão de futuro desse Portal RH, ou seja, onde 
queríamos chegar com o Portal RH e a estratégia, ou seja, o 
caminho para chegar lá. E com os PMs, é responsável pela 
execução dessa estratégia. 


3.2 Liderança interina 


Imagino que você já tenha visto alguma situação em que a pessoa é 
uma excelente colaboradora, recebe uma promoção para liderar 
pessoas e, por não estar preparada ou até mesmo por descobrir que 
não gosta de liderar pessoas, acaba tendo um perfomance ruim 
como gestora. Só que essa pessoa entende que não pode voltar 
atrás, voltar a uma posição de contribuidor individual pode ser visto 
como um retrocesso na carreira, como uma falha. 


Uma ferramenta interessante para prevenir situações como essa é o 
conceito de interinidade. Ao invés da pessoa já assumir um cargo 
permanente de GPM e liderar uma ou mais pessoas, pode-se usar o 
conceito de GPM interino, ou seja, é a pessoa assume esse papel 


de forma temporario, como um teste para ela ver se gosta e se 
sente confortável fazendo a função de lider. Essa ferramenta pode 
ser usada em qualquer carreira, não somente na carreira de gestão 
de produtos. De engenheiro para líder de engenheiros, de product 
designers para líder de UX etc. 


Essa ferramenta cria uma salvaguarda, uma rede de proteção para 
as pessoas que nunca lideraram pessoas e querem experimentar 
essa opção de carreira. Com essa ferramenta há espaço para voltar 
atrás caso a pessoa não goste ou não se sinta preparada para 
exercer essa função. É o famoso conceito de change rollback ou 
undo que permite desfazer uma mudança e voltar à versão anterior 
caso a gente perceba que a mudança feita não está funcionando 
como esperado. 


3.3 CPO ou VP de Produto 


O Chief Product Officer (CPO) ou Vice-Presidente de Produtos é o 
cargo mais alto de produtos em uma empresa. Lidera GPMs ou 
diretores de produto e tem por responsabilidade coordenar a 
definição da visão e da estratégia de todos os produtos da empresa, 
bem como pela execução dessa estratégia, em conjunto com os 
GPMs e diretores de produto. Em alguns casos pode fazer sentido a 
área de UX reportar para o CPO. Idealmente, dada a importância da 
estratégia digital nas empresas, o cargo de CPO deve reportar para 
o CEO e ter acesso aos membros do Conselho. 
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Figura 3.4: Carreira de produtos 


A nomenclatura pode ser um pouco confusa. Algumas empresas 
chamam essa posição de head de produto, outras de diretor de 
produto ou vice-presidente de produto ou CPO. Apesar disso, o 
importante é a estrutura estar clara para todos dentro e fora do time 
de desenvolvimento de produtos. 


Existem dois modelos de estrutura de liderança de times de 
desenvolvimento de produto, cada um com os seus prós e seus 
contras, a depender do contexto onde está esse time: 


Liderança única 


Tanto na Locaweb quanto na Conta Azul eu tive o papel de CPO 
com a responsabilidade de liderar todo o time de desenvolvimento 
de produto, ou seja, gestores de produto, product designers e 
engenharia. 


A liderança única funciona quando se tem pessoas sêniores para 
ajudar na gestão de engenharia assim como na gestão de design e 
de produtos. Na Conta Azul, o time chegou a ter 130 pessoas e eu 
tinha um head de engenharia, 4 GPMs e um head de design para 
me ajudar. Na Locaweb, com um time de 100 pessoas eu tinha dois 
gerentes seniores de engenharia, 5 PMs seniores e um head de UX. 


Gosto dessa configuração pois sempre vi o time de desenvolvimento 
de produto como um único time, com objetivos comuns de entregar 
o melhor produto para atender aos objetivos da empresa enquanto 
resolve problemas e necessidades dos usuários. Essa configuração 
ajuda no alinhamento e nessa visão de time único. 


Esse tipo de configuração funciona muito bem para times pequenos, 
de até umas 80 a 100 pessoas. Quando chega nesse tamanho, 
existe o risco de sobrecarregar esse líder único responsável por 
todo o time de desenvolvimento de produto. É uma infinidade de 
temas diferentes, daí a importância de ter pessoas seniores 
ajudando na liderança. 


Em algumas empresas, ao invés de CPO, essa liderança única é 
chamada de Chief Technical Officer (CTO) ou de Vice-Presidente de 
Desenvolvimento de Produtos. 


Pode fazer sentido pensar em dividir a área em duas lideranças 
quando o time cresce para mais de 100 pessoas, tendo um CPO e 
um CTO fazendo a liderança compartilhada. Vale lembrar de que a 
liderança compartilhada, apesar de ser benéfica no sentido de dividir 
responsabilidades, pode ter efeitos colaterais prejudiciais se não for 
bem gerenciada pelo CEO. 


Liderança compartilhada 


No Gympass rodamos durante 18 meses com um CTO e dois 
CPOs, sendo um de produtos para consumers e eu focado em 
produtos para empresas e parceiros. Optamos por essa 
configuração pois prevíamos um crescimento considerável do time. 


Quando o time estava ainda com 60 pessoas, já vislumbravamos 
um crescimento ate 400 pessoas. Poder dividir a responsabilidade, 
principalmente quando o time cresce rapido para números acima de 
100 pessoas, ajuda a colocar mais atenção e ir mais fundo nos 
temas de que cada líder cuida. Isso evita a sobrecarga que 
comentei acima. 


CTO CPO End-user CPO B2B & Partners 


Eng Dirs Inf Dirs Prod Dirs UX Head Prod Dirs PS Dir | 











50 a 500 
pessoas 






































Figura 3.5: Estrutura de liderança de desenvolvimento de produtos no Gympass 


No Gympass, o time de UX reportava para o CPO de consumers 
enquanto eu tinha, além dos times de produto para empresas e 
parceiros, um time de Professional Services (PS) que era 
responsável por fazer as integrações customizadas com sistemas 
de academias e de sistemas de RH de nossos clientes. Esse 
trabalho de professional services é mais orientado a projetos, com 
definição clara de escopo e prazos bem definidos, por isso criamos 
uma área separada para cuidar dessas integrações. 


Na Conta Azul, quando eu saí de lá em meados de 2018, 
estávamos começando a pensar em dividir os papéis entre CTO e 
CPO. Tanto que agora em 2020 há lá essa estrutura com a liderança 
compartilhada do time de desenvolvimento de produtos. 


CTO || GPM (4) | UX Head | 


| Sr Eng Mgr (2) | Sr Inf Mgr | GPM (4) | | UX Head | 


Figura 3.6: Estrutura de liderança de desenvolvimento de produtos na Conta Azul 
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Outra possibilidade de liderança compartilhada de times de produto 
é ter head de engenharia, de produtos e de UX. 


A liderança compartilhada tem por efeito colateral o risco inerente de 
criação de silos, ou seja, de haver times trabalhando de forma 
isolada e sem a necessária colaboração. No Gympass, tínhamos 
uma preocupação forte em evitar esse comportamento. Sentávamos 
nós 3 lado a lado e reservávamos no mínimo três horas por semana 
para conversarmos sobre temas do time de desenvolvimento de 
produtos, sendo uma hora entre nós 3, uma hora junto com 
business partner de RH, e uma hora com o CEO. Além disso, 
buscávamos setar os objetivos de forma comum para os times e 
tratávamos o orçamento como um orçamento único da área de 
desenvolvimento de produtos. 


Contudo, apesar de nossos esforços, ainda assim havia situações 
de falta de colaboração entre os membros de diferentes times. Por 
este motivo, tenho preferência por configurações com liderança 
única de time de desenvolvimento de produtos, apesar da eventual 
sobrecarga que isso possa causar nessa liderança. Uma forma de 
diminuir essa sobrecarga é contar com líderes seniores. 


CPO e CTO 


Como comentei anteriormente, a área de desenvolvimento de 
produtos é uma área só, com objetivo comum de criar o melhor 
produto para atender aos objetivos estratégicos da empresa 
enquanto resolve problemas e necessidades dos clientes. Ter duas 
ou mais lideranças para essa área requer bastante coordenação 
entre elas para garantir que os times estão colaborando e evoluindo 
na mesma direção. A forma mais comum de dividir essa liderança é 
ter duas pessoas, CPO e CTO, para liderar o time de 
desenvolvimento de produtos. Enquanto o CPO lidera pessoas de 
produto e de UX, o CTO lidera as pessoas de engenharia. 
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Figura 3.7: Divisão de responsabilidades entre CTO e CPO 


Essa imagem ilustra bem as responsabilidades de cada liderança. O 
CTO cuida do desenvolvimento propriamente dito do produto, ou 
seja, tem que se preocupar com a qualidade do que está sendo 
desenvolvido, bem com a velocidade de desenvolvimento. Também 
cuida de questões de infraestrutura e operacionais tais como a 
estabilidade, performance e disponibilidade do produto. O CPO 


cuida do produto tanto do ponto de vista do negócio quanto do ponto 
de vista do cliente. Do ponto de vista do negócio, é responsável por 
definir a visão de produto alinhada com os objetivos estratégicos do 
negócio. Do ponto de vista do cliente, precisa garantir que o produto 


resolve um problema ou necessidade do cliente com qualidade e, 
para isso, ele precisa entender a satisfação e o engajamento do 
cliente com o produto. 


Em conjunto, CTO e CPO devem definir e evoluir a estrutura do time 
de desenvolvimento de produto, com times de produto e times 
estruturais (SRE, Data etc.) como veremos no capítulo Estrutura de 
times, bem como definir e evoluir os processos que esse time usará 
no seu dia a dia. 


3.4 Carreira Y 


Carreira Y é a opção que se dá para as pessoas optarem pela 
carreira gerencial ou seguir na carreira de especialista. Alguns PMs 
mais seniores podem não querer gerir pessoas, só produtos. Isso 
significa que não há espaço para ela evoluir na carreira, uma vez 
que o caminho de progressão visto acima passa pela liderança de 
outros PMs? Não necessariamente. 


Em empresas com produtos mais complexos ou até mesmo com um 
portfólio de mais de um produto, pode haver espaço para um papel 
pouco conhecido no mercado brasileiro, mas que pode ajudar 
bastante nesse contexto, o Principal Product Manager. Esse é um 
papel que não gerencia pessoas mas que, pela sua senioridade, 
tem um impacto relevante na organização. Suas principais 
responsabilidades são: 


Ajudar a conectar o trabalho dos GPMs: à medida que a empresa 
cresce e temos mais de um time de desenvolvimento de produto, 
cada um com seu GPM muitas vezes focado no dia a dia desse 
time, sem olhar muito para o que os outros times estão fazendo, 
normalmente é papel do CPO manter a conexão entre o trabalho 
dos diferentes times e seus GPMs mas, em algumas estruturas, 
pode fazer sentido ter algum PM bem sênior fazendo esse papel. 


Garantir a sincronia e consisténcia entre os times de produto: 
por independentes que tentemos fazer a estrutura de times de 
produto, sempre haverá situações em que um time dependerá do 
trabalho de outro time. Um exemplo no Gympass são os times de 
produto para academia e para usuário final. O time de academia faz 
uma funcionalidade que permite ao gestor da academia criar o 
horário de aulas, e o time focado no usuário final precisa colocar 
esse horário de aulas disponível no app para que os usuários 
passam ver e agendar aulas. Essa coordenação normalmente é 
feita pelos próprios PMs desses dois times, mas eles podem se 
beneficiar de ter uma terceira pessoa ajudando nessa coordenação. 
Essa terceira pessoa pode ser um GPM, o CPO ou mesmo um PM 
mais sênior, nesse papel de Principal Product Manager. 


Note que essas responsabilidades são um subconjunto das 
responsabilidades de um head de produto ou mesmo de um CPO, 
sem a responsabilidade pela gestão e desenvolvimento dos PMs, o 
que pode ser atraente como progressão de carreira para pessoas 
que não queiram gerir outras pessoas. Esse papel ainda é novo. 
Algumas empresas o enxergam como sendo somente um PM muito 
sênior, mas acho que faz sentido pensar nesse papel com uma 
contribuição maior do que somente em um time. 


3.5 Resumindo 


e À carreira de produto tem a progressão de Associate Product 
Manager (APM) para Product Manager (PM) para Group 
Product Manager (GPM) para Chief Product Officer (CPO). 
Existem algumas variações de nomenclatura a depender da 
empresa e do país, mas em geral segue essa progressão. O 
importante é essa estrutura e progressão de carreira estarem 
claras para toda a empresa. 


e Quando se fala da liderança mais sênior de produto em uma 
empresa, há duas opções com seus prós e contras. Uma opção 
é a liderança única de todo time de desenvolvimento de 
produtos (PM, UX e engenharia), que funciona bem para times 
menores, mas pode sobrecarregar quando são times de mais 
de 100 pessoas. A vantagem é ter todo o time alinhado com 
uma única liderança. A outra opção é a liderança 
compartilhada com CPO e CTO, que evita a sobrecarga em 
times grandes, mas pode causar uma diminuição de 
colaboração caso não haja boa sintonia entre esses dois ou 
mais líderes. 


e Para PMs que não querem seguir a carreira de gestão, é 
importante dar a opção da carreira em Y, com o papel de 
Principal Product Manager, que ajuda na integração e sincronia 
do trabalho dos diferentes times. 


No próximo capítulo vamos olhar uma das principais 
responsabilidades do head de produtos, a criação da visão e da 
estratégia de produto. 


CAPITULO 4 
Visao de produto 


Apesar de ser apenas 10% do tempo de um lider de produto, 
definição de visão de produto é sua responsabilidade mais 
importante. Sem a clareza de visão de produto, fica muito difícil 
trabalhar em qualquer outro tema em relação ao produto. Quais são 
as prioridades? Que estrutura de time de produto é necessária? 
Esse pedido do time comercial é importante”? E esse do time de 
suporte ao cliente? E esse pedido do CEO/Founder? Devemos focar 
em ter mais clientes ou em reter os que já temos”? Essas perguntas 
são muito difíceis de responder se não houver clareza sobre a visão 
de produto. 


Quando me junto a uma nova empresa, quer seja em um papel de 
tempo integral, quer seja em meus trabalhos de mentoria, minha 
primeira preocupação é entender se existe uma visão de produto e 
se ela está clara para todos na empresa. Esse é sempre o meu 
primeiro foco, pois da visão de produto deriva todo o trabalho de 
desenvolvimento de produto. 


4.1 O que é visão de produto? 


A visão de produto nada mais é do que o entendimento de como 
será o seu produto no futuro. Por "futuro" quero dizer médio a longo 
prazo, OU seja, um horizonte de mais de 2 ou 3 anos. Como ele vai 
atingir os objetivos da empresa que é dona do produto enquanto 
resolve problemas e necessidades seus usuários? 


Construir a visão de produto é um trabalho colaborativo feito em 
conjunto com várias pessoas de dentro da organização, assim como 
com input de pessoas de fora como clientes e não clientes, 


fornecedores, concorrentes, especialistas do mercado etc. Esse é 
um trabalho liderado pelo head de produto, quer seja ele um VP ou 
CPO, quer seja ele um GPM. Se for um VP ou CPO, a visão terá por 
escopo todos os produtos da empresa ou da área, enquanto que, se 
for um GPM, o foco da visão será o produto, ou pedaço de produto, 
de que esse GPM cuida. Para o GPM conseguir fazer sua visão, ele 
precisa ter clareza da visão de produto da empresa. 


Para fazer a visão de produto, é preciso ter clareza sobre os 
objetivos da empresa com o produto, bem como entender 
profundamente os problemas e as necessidades que os clientes têm 
e que serão resolvidos pelo produto. Alguns exemplos de visão de 
produto que ajudei a criar: 


Produto E-mail da Locaweb 


Durante meu período na Locaweb, montamos a seguinte visão de 
produto para o produto E-mail da Locaweb: 


O produto E-mail da Locaweb será a solução de email MAIS 


COMPLETA E FLEXÍVEL do mercado brasileiro. 





Visão de produto da Conta Azul 


Criamos a visão de produto da Conta Azul como uma imagem, 
porque com a imagem era mais fácil explicar todos os elementos do 
que víamos como o futuro do produto da Conta Azul. 


Visão da Conta Azul: uma plataforma de múltiplos lados 
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Figura 4.1: Visao de produto da Conta Azul 
Visao de produto do Gympass 


Novamente, preferimos uma imagem em vez de palavras. O chavao 
uma imagem vale mais que mil palavras tem uma razao para existir. 


Visao da Gympass: um mercado de 3 lados 
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Figura 4.2: Visao de produto do Gympass 
Visao de produto da Lopes 


E aqui mais uma vez fizemos uso de uma imagem. 


Visao Lopes: tri-match 
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Figura 4.3: Visão de produto da Lopes 


4.2 Processo de criação de visão de produto 


Aqui vai um passo a passo de como criar a visão de produto: 


Obter objetivos estratégicos da empresa: se você ainda não tem 
essa informação, vá obtê-la. Converse com os líderes da empresa, 
o CEO, os founders, o conselho. Claro que toda empresa quer 


crescer e ter mais receita e clientes, mas como? Quais sao os 
objetivos da empresa, e qual é a estratégia para atingi-los? 


Obter entendimento dos problemas e necessidades dos 
clientes: se isso ainda não estiver claro, existem várias ferramentas 
que ajudam. Mapa de empatia e personas são ferramentas úteis 
para obter essa informação. Existem várias outras, tais como 
observação, entrevista, pesquisa, job to be done etc. para você 
obter essa informação. 


Desenhar primeira versão da visão: estando de posse das duas 
informações você já consegue fazer a primeira versão da visão de 
produto. Esse é um trabalho de criação e é mais produtivo se feito 
sozinho. Já experimentei fazer esse trabalho em conjunto com 
outras pessoas e o processo acabou sendo demorado e o resultado 
não foi tão bom por ter várias pessoas discutindo algo que ainda 
não existia. Baseado em minha experiência, é mais produtivo e gera 
melhores resultados quando o head de produto faz a primeira 
versão e, a partir dela, faz iterações para colher feedback e refinar a 
visão. 


Iterar e refinar: uma vez feita a primeira versão da visão de 
produto, é hora de iterar e refinar. As primeiras pessoas com quem 
se iterar são as pessoas do próprio time de desenvolvimento de 
produto. PMs, GPMs, designers, engenheiros. Ouça o feedback 
deles e refine a visão de produto com base nele. Em seguida, 
apresente para as lideranças das outras áreas, gerentes, diretores, 
C-level, founders, conselhereiros, mais feedback e refinamento. 
Tenho preferência por fazer essas sessões de feedback e 
refinamento individualmente. Apesar de dar mais trabalho, dá a 
oportunidade de todos falarem. 


Comunicar: feitas as iterações e refinamentos da visão de produto 
em sessões 1:1 com os stakeholders, o próximo passo é comunicar 
essa visão para toda a empresa e até mesmo para fora da empresa. 
Isso deve ser feito repetidamente. Em todas as oportunidades 
relembre a visão de produto. Eu costumo usar a visão de produto 


em todos os momentos possíveis. Reuniões de all-hands, de 
produto, de diretoria, de onboarding etc. Uso até mesmo 
publicamente em palestras e artigos, para explicar como 
enxergamos o futuro do produto em nossa empresa. Uso também 
em conversas com candidatos, para ajudá-los a entender o que 
estamos construindo e se animar a se juntar conosco. 


Revisar: periodicamente é importante revisar a visão, ver se todos 
os seus elementos ainda fazem sentido e se algo novo precisa ser 
incluído. Minha sugestão é fazer essa revisão uma vez por ano, ou 
quando algo novo aparece, como um novo concorrente, ou alguma 
mudança no mercado. 


Pronto, esses são os passos para fazer a visão de produto. 


4.3 Resumindo 


e Apesar de ser apenas 10% do tempo de um líder de produto, 
definição de visão de produto é sua responsabilidade mais 
importante. Sem ela todo o trabalho de desenvolvimento de 
produto fica muito mais difícil. 


e A visão de produto nada mais é do que o entendimento de 
como será o seu produto no futuro. 


e Para fazer a visão de produto é preciso ter clareza sobre os 
objetivos da empresa com o produto, bem como entender 
profundamente os problemas e as necessidades que os clientes 
têm e que serão resolvidos pelo produto. 


e Os 6 passos para construir uma visão de produto são: obter 
objetivos estratégicos da empresa, obter entendimento dos 
problemas e necessidades dos clientes, desenhar primeira 
versão da visão, iterar e refinar, comunicar e revisar. 


No próximo capítulo vamos ver qual o caminho para executar a sua 
visão de produto. 


CAPITULO 5 
Estrategia e objetivos 


O que precisa ser feito para que seu produto se aproxime da visao 
de produto? São sua estratégia e seus objetivos. Estamos falando 
em definir o que fazer, como fazer, em que ordem e que métricas 
nos dizem que estamos indo na direção certa, uma vez que o motivo 
por que fazer já foi definido na visão de produto. 


A estratégia e os objetivos provêm um caminho a ser seguido e as 
métricas que mostram se estamos ou não no caminho certo. Sem 
isso claramente definido é muito difícil definir qual o time mais 
apropriado e o que precisa ser feito para atingir esses objetivos. 


5.1 Criando sua estratégia de produto 


Como você já tem clareza da sua visão de produto, você precisa 
entender o que é preciso fazer para executá-la para chegar aonde 
você quer chegar. A seguir estão algumas ferramentas que ajudarão 
você a criar sua estratégia de produto: 


Análise de mercado 


Para criação da sua estratégia, você precisa ter um bom 
entendimento do seu mercado em relação a cinco aspectos: 


Concorrentes: tanto os diretos quanto os indiretos, ou seja, aqueles 
que competem pelo tempo e atenção do seus usuários. Por 
exemplo, um concorrente da atividade física são os serviços de 
streaming, que motivam seus usuários a assistirem cada vez mais 
vídeos. 


Mercado potencial e acessivel: quanto mercado, ou seja, quantas 
pessoas poderiam ser seus clientes? Para poder ser seu cliente, 
existe algum requisito minimo? Por exemplo, se vocé vende um 
curso online para estudantes de medicina se prepararem para o 
processo de avaliação para ingressar em um programa de 
residência médica, seu mercado potencial são todos os estudantes 
de medicina dos últimos anos de graduação. Esse é seu mercado 
potencial. E desse total de pessoas, com quantas você de fato 
consegue falar e mostrar seu produto, e que vão querer usá-lo? 
Esse é seu mercado acessível. 


Crescimento do mercado: o número de pessoas com potencial de 
usar o seu produto está crescendo, estável ou diminuindo? E o 
número de pessoas com quem você consegue falar sobre o seu 
produto? É muito importante você entender se o mercado que você 
enxerga para o seu produto está crescendo, estável, ou diminuindo, 
e se esse movimento é de curto ou longo prazo. Entender como o 
seu mercado está se comportando é fundamental para ajudar a 
definir sua estratégia. 


Disruptores: tão importante quanto conhecer seus concorrentes 
diretos e indiretos, é preciso conhecer que produtos podem 
disromper o seu produto, ou seja, substituir o benefício que seu 
produto entrega de uma maneira melhor e mais atraente para seus 
usuários. Por exemplo, as pessoas estão usando cada vez menos 
email em função das opções de comunicação que produtos de 
mensagem direta como WhatsApp e Slack têm oferecido. 


Regulamentação: seu mercado é regulado? Você conhece essa 
regulação? Houve mudanças nessa regulação? Por exemplo, na 
conta Azul monitorávamos diariamente a regulação fiscal e contábil 
para garantir que o produto estivesse alinhado com essas 
regulações. 


Esse trabalho deve ser coordenado pelo head de produto em 
conjunto com a liderança de marketing. Provavelmente esse tipo de 
análise tem sido feito de forma pontual. Minha recomendação é 


transformar a analise de mercado uma disciplina permanente, isto é, 
uma vez criada a primeira versao com os itens acima, atualizar 
mensalmente para garantir ter as informações mais atualizadas 
sobre o seu mercado. 


Análise SWOT 


De posse da sua análise de mercado, o próximo passo é entender a 
posição do seu produto nesse mercado. Tanto a posição atual, 
quanto a posição que você deseja ocupar quando tiver executado 
sua visão de produto. Uma boa ferramenta para ajudar nesse 
entendimento é fazer uma análise SWOT, sigla em inglês para 
Strengths, Weaknesses, Opportunities and Threats, ou pontos 
fortes, fracos, oportunidades e ameaças do seu produto. Já 
encontrei versões em português com o nome FOFA - pontos Fortes, 
Oportunidades, Fraquezas e Ameaças. 
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Figura 5.1: Análise SWOT 


Os pontos fortes e os pontos fracos são itens internos (do seu time 
de desenvolvimento de produto, ou da sua empresa) sobre as quais 
você, seu time ou sua empresa têm algum controle, que ajudam ou 
atrapalham o seu produto para atingir a sua visão. As oportunidades 
e ameaças são os elementos externos à organização, isto é, sobre 
os quais a organização não tem controle, e que podem influenciar 
positiva ou negativamente no atingimento da visão do produto. Tem 
a ver com a análise de mercado descrita anteriormente. 


Preencher o SWOT deve ser um trabalho de equipe. O head de 
produtos deve ter uma ou mais sessões junto a pessoas que podem 
contribuir para essa analise. Lideres do seu time e de outras areas 
sao a audiéncia indicada para esse tipo de sessao. Como organizar 
uma sessão de análise SWOT: 


e Lição de casa: peça para todos preencherem cada um uma 
análise SWOT. Limite a, no máximo, três itens por quadrante. É 
comum, principalmente no quadrante das fraquezas, as 
pessoas criarem uma lista bem grande de itens, não raro com 
mais de 10 fraquezas. Ao pedir para limitar por 3 itens por 
quadrante, as pessoas serão forçadas a fazer uma primeira 
priorização. 


e Consolidação: junte todas as análises SWOT em uma única. 
Haverá algumas sobreposições e algumas diferenças. Coloque 
os itens em cada quadrante com a quantidade de pessoas que 
colocou cada item em sua análise SWOT individual. Essa 
quantidade pode servir como um primeiro indício de priorização. 


e Versão final: junte as pessoas em uma conversa para avaliar a 
versão consolidada. O objetivo agora é fazer a versão 
consolidada também ter no máximo 3 itens por quadrante para 
forçar a todos a mais uma vez priorizar. Normalmente uma 
unica sessão pode ser suficiente para construir essa versão 
final. 


Uma vez tendo sua versão final da análise SWOT, você tem 12 itens 
que podem servir de foco da sua estratégia. Digo que "podem" pois 
você não precisa trabalhar em todos os itens ao mesmo tempo. 
Aqui, mais uma vez, entra a capacidade de priorização, lembrando 
que o SWOT foi feito para nos ajudar a mostrar o caminho que 
precisa ser percorrido para atingirmos nossa visão de produto. 


e Pontos fortes: como mantê-los relevantes? É preciso fazer 
algo para reforçá-los? Algum dos pontos fortes é mais 
importante que os outros? 


e Fraquezas: como diminuir o impacto das fraquezas? Qual 
dessas fraquezas tem impacto maior? 

e Oportunidades: é possível explorar as oportunidades? O que 
podemos fazer para isso? Qual é mais relevante para a 
execução da visão de produto? 

e Ameaças: o que devemos fazer para nos proteger das 
ameaças? Como essas ameaças impactam a execução da 
visão de produto? 


Essas discussões também devem ser feitas em grupo, e podem até 
mesmo ser feitas na continuação da criação da análise SWOT. Com 
isso você já terá um alinhamento entre a liderança das diferentes 
áreas sobre a estratégia de produto. 


OKR 


OKR vem do inglês Objective and Key Results, objetivos e 
resultados principais. É uma ferramenta de gestão que serve para 
alinhar e acompanhar a execução da estratégia. Essa ferramenta é 
usada no Google desde seu início e foi levada para lá por John 
Doerr, um funcionário da Intel, empresa onde foi criada. Várias 
empresas de tecnologia hoje usam OKRs, tais como Locaweb, 
Conta Azul, Gympass, Linkedin, Amazon, Adobe, Baidu, Dropbox, 
Facebook, Netflix e Spotify. OKR é um framework derivado de uma 
técnica de gestão chamada de Administração por Objetivos, termo 
criado por Peter Drucker em seu livro The Practice of Management, 
de 1954. 


É uma ferramenta bastante simples e poderosa. Você define junto 
do time alguns objetivos para um período - normalmente um 
trimestre ou um ano - e define em quais métricas vocês vão mexer 
para mostrar que o objetivo está sendo atingido. Cada objetivo 
poderá endereçar um ou mais itens de sua análise SWOT ou 
representar algo que vocês querem executar da sua visão. 


Por exemplo, digamos que um de seus objetivos seja "Atingir 
recordes de compras por mês em nosso site”. Para atingir esse 


objetivo, você pode definir as seguintes métricas: 


e Aumentar de 15.000 para 20.000 visitas por semana. 

e Melhorar a taxa de conversão de 4,5% para 6%. 

e Diminuir o bounce rate de 35% para 20%. 

e Melhorar o tempo de carregamento das páginas para menos de 
2 segundos. 


O time deve olhar os OKRs todas as semanas para ver se as 
métricas estão mexendo e entender se há algum impedimento a ser 
removido ou algo a ser feito para acelerar o atingimento dos 
objetivos. Entregas e medições mais frequentes ajudam. Se houver 
entregas e medições apenas mensais, o time só terá duas chances 
no trimestre para testar sua ideia de como mexer a métrica. Se 
houver entregas e medições semanais, são 12 oportunidades de 
avaliar e mudar o rumo se necessário. 


Quanto mais próximo dos objetivos e das métricas de negócio forem 
os OKRs, melhor será para o time pois ele estará trabalhando para 
ajudar a empresa em seus objetivos e resultados. 


Pronto, você agora tem a estratégia de seu produto, os objetivos 
que você quer alcançar e as métricas que dirão se você está 
atingindo seus objetivos. Seu próximo passo será definir a estrutura 
de time mais apropriada para executar sua estratégia e atingir seus 
objetivos, tema do próximo capítulo. 


5.2 Revisando sua estratégia de produto 


Um ponto importante é que seu produto evolui à medida que o time 
trabalha nele e você se aproxima da sua visão de produto. Muito se 
aprende sobre os usuários do produto, seus problemas e 
necessidades e com isso novas alternativas podem aparecer para 
ajudar seu usuário a resolvê-los. O dono do produto também pode 


revisitar seus objetivos estratégicos e, consequentemente, revisitar 
os objetivos definidos para o produto digital. 


Além disso, pontos fortes e pontos fracos podem mudar com o 
tempo, e oportunidades e ameaças podem aparecer ou sumir. Por 
isso, é importante entender que nem a visão, nem a estratégia, nem 
os objetivos do produto estão escritos em pedra. Elas podem e 
devem ser revisitadas periodicamente. Minha sugestão é isso seja 
feito anualmente, ou quando algum evento relevante acontecer, 
como quando houver uma mudança nos objetivos estratégicos da 
empresa, ou quando aparecer uma alternativa que resolve o 
problema ou necessidade do usuário de uma forma diferente da do 
seu produto, ou quando acontece uma crise como a pandemia da 
COVID-19. Já para os OKRs, minha sugestão, como comentado 
anteriormente, é que eles sejam definidos trimestralmente e 
revisados semanalmente. Isso dará ao seu time uma boa cadência 
de execução. 


5.3 Resumindo 


e Estratégia de produto nada mais é do que o caminho que 
você vai seguir para chegar à sua visão de produto. 


e Para criar sua estratégia de produto você precisa ter bastante 
entendimento sobre seu mercado, ou seja, os concorrentes, o 
mercado potencial e acessível, o crescimento desse 
mercado, se existem disruptores e como esse mercado é 
regulado. 


e Utilize a análise SWOT para ajudar a definir que pontos você 
vai trabalhar em sua estratégia de produto. 


e Utilize OKRs para ajudar a definir os objetivos de sua estratégia 
e as métricas que dirão se você está no caminho correto. 


e Revise pelo menos anualmente, ou quando houver eventos 
relevantes no mercado, a sua estratégia e sua visão de produto. 
O mercado muda, seu produto evolui, então sua visão e 
estratégia de produto também deve evoluir. Os OKRs devem 
ser revistos trimestralmente. 


No próximo capítulo vamos ver diferentes formas de estruturar o 
time de desenvolvimento para poder executar a estratégia de 
produto a fim de atingir a visão de produto. 


CAPITULO 6 
Estrutura de time 


O time de desenvolvimento de produto é quem vai executar a 
estratégia e atingir os objetivos para alcançar a visão de produto. 
Por isso, uma parte essencial da definição de estratégia é desenhar 
e implementar sua estrutura de time. Para isso, é importante 
entender as diferentes formas de se organizar um time de 
desenvolvimento de produtos e definir qual a mais apropriada para a 
sua estratégia. 


6.1 Times de produto 


O time mínimo de desenvolvimento de produto que vimos no 
capítulo sobre Carreira de gestão de produtos é composto um 
product manager, um product designer e dois ou mais engenheiros. 
Esse time mínimo pode também ser chamado de squad e deve ter 
no máximo umas 7 pessoas. Quanto maior o time, maior a 
dificuldade de coordenação. Na Amazon existe a famosa regra dos 
times de duas pizzas, ou seja, o tamanho máximo do time é aquele 
que consegue ser alimentado por duas pizzas grandes. O racional 
por trás da vantagem de rodar com times pequenos é baseado no 
mesmo conceito que apresentei quando falei de plataformas no 
capítulo O que é produto digital e gestão de produtos?. A 
quantidade de interações entre os membros do time crescem 
rapidamente com o tamanho do time, seguindo a fórmula n*(n-1)/2. 
Assim, enquanto um time de 5 pessoas tem 10 possibilidades de 
interação entre seus membros, em um de 7 pessoas esse número 
cresce para 21. 


Quando juntamos dois ou mais squads temos um time de produto, 
que também pode ser chamado de tribo. 


times de produto 


Liderança 





Figura 6.1: Times de produto 


Essa tribo de produto pode ter um, dois ou três líderes. Se for uma 
líder, ela será responsável por liderar product managers, product 
designers e engenheiros. Se forem dois líderes, normalmente um 


vai liderar product managers e product designers, e o outro liderara 
engenheiros. Se forem trés, um lidera product managers, outro, 
product designers e o terceiro, engenheiros. Ja tive oportunidade de 
trabalhar em estruturas com um, dois e trés lideres em cada tribo de 
produto e cada uma dessas estruturas traz seus pontos positivos e 
negativos, como expliquei no capítulo sobre Carreira de gestão de 
produtos onde falo sobre liderança única e liderança compartilhada. 


Times de produto também podem ter alguns papéis compartilhados 
entre os squads. Tê-los compartilhados ao invés de dedicados por 
squad tem três principais objetivos: 


e Tamanho de squad: manter o squad pequeno é importante 
para conseguir preservar a agilidade desse time. Quanto maior 
o time, maior a necessidade de coordenação entre os membros 
do time. 


e Ownership: a partir do momento em que você tem uma pessoa 
no squad com uma função específica, essa função deixa de ser 
responsabilidade dos outros membros do time. Por exemplo, se 
tivermos uma pessoa cuidando da qualidade, esse tema virará 
responsabilidade dela, e as outras pessoas do squad vão se 
preocupar menos com o tema. As exceções são as três funções 
primárias de um squad que são engenharia, design de produto 
e gestão de produto. 


e Alocação de recursos: além de o squad ficar grande se 
colocarmos esses papéis dentro dele, necessitando de mais 
coordenação e tendo o risco de ficar mais lento, cada squad 
custará mais caro. Com squads menores, temos a possibilidade 
de alocar os recursos que você tem disponível para 
desenvolvimento de produto em mais squads que constroem 
produto. 


Exemplos de papéis que podem existir em uma tribo de produto 
compartilhado entre os diferentes squads: 


Agile Coach: ajuda os squads em seus processos e cultura 
agil. Em vez de um scrum master por squad, tem-se um agile 
coach por tribo que ajuda os squads nesse tema, mas os 
processos e a cultura ágil de cada squad é responsabilidade de 
cada membro do squad. 


Quality Assistance: assim como processos e cultura ágil são 
responsabilidade de cada membro do squad, o mesmo 
acontece com qualidade. Em vez de um quality assurance por 
squad, podemos ter um quality assistance por tribo de produto, 
que vai ajudar cada squad com questões de qualidade. 


Data Analyst: todo squad gera muitos dados e precisa 
entender o que esses dados querem dizer. De novo, entender o 
que esses dados significam é uma responsabilidade do squad. 
Contudo, quando a estrutura de dados é muito complexa, pode 
fazer sentido ter uma pessoa por tribo de produto ajudando 
seus squads nas necessidades mais complexas de dados de 
cada squad. 


SRE: para produtos com muita integração com sistemas de 
terceiros pode ser interessante ter um Site Reliability Engineer 
(SRE) por tribo ajudando os squads a definir e implementar 
arquiteturas estáveis, com boa performance e resilientes. Na 
Conta Azul, como tínhamos integração com bancos e com os 
sistemas das Secretarias da Fazenda de cada estado para 
emissão de nota fiscal, fez sentido termos uma pessoa com 
esse conhecimento em cada tribo. 


User Research: essa é a responsabilidade dos product 
designers, com apoio dos gestores de produto de cada squad. 
Em alguns casos, pode fazer sentido ter uma pessoa com foco 
em research na tribo de produto para ajudar nessas pesquisas 
de cada squad. 


Product Marketing: enquanto a missão da gestora de produtos 
é construir o produto ou funcionalidade que resolve problemas 


dos usuários, o product marketing tem por missão contar ao 
mundo sobre o produto ou funcionalidade e o problema que ele 
resolve. Esse "mundo" refere-se tanto aos usuários do produto 
quanto aos novos usuários que queremos trazer. É responsável 
por desenhar e implementar a estratégia de go to market (GTM) 
do produto. Em muitas empresas essa responsabilidade recai 
sobre a gestora de produtos. Isso funciona em muitos casos, 
mas pode tirar seu foco em construir o melhor produto ou 
funcionalidade. 


Há outros papéis que podem ser compartilhados mas lembre-se de 
que, quanto mais papéis compartilhados tiver, mais difícil ficará a 
coordenação das pessoas da tribo. Minha recomendação é ter no 
máximo 3 papéis compartilhados. Eles podem ser liderados pela(s) 
líder(es) da tribo ou pela líder da tribo estrutural correspondente à 
sua função. 


6.2 Organizando times de produto 


Existem 4 formas possíveis de se organizar times de produto, por 
produto ou funcionalidade, por tipo de usuário, por jornada ou por 
objetivo. É possível também usar dois tipos diferentes de 
organização criando uma organização híbrida. Vou descrever a 
seguir cada uma: 


Por produto ou funcionalidade 


É uma das formas mais comuns de organização de times de 
produto. Para cada produto ou funcionalidade temos uma tribo. Na 
Locaweb tínhamos time de produto para cada produto, Email 
Marketing, PABX virtual, cloud, hospedagem de sites e assim por 
diante. Na Conta Azul também usávamos esse modelo, com um 
time, o Spartans, focado em funcionalidades relacionadas à gestão 
financeira e o outro time, o Underground, focado em funcionalidades 


fiscais e contábeis. Na Lopes, quando entrei, tínhamos um time 
focado no portal, outro no CRM utilizado pelos corretores e 
franquias e um terceiro focado no app para corretores. 


A principal vantagem desse forma de organização é que a parte do 
produto que é responsabilidade da tribo é bem clara mas, por outro 
lado, com o foco no produto perde-se um pouco de perspectiva 
da(s) pessoa(s) cujos problemas esse produto resolve. 


Por tipo de usuário 


Esse é um modelo muito útil em marketplaces e plataformas. Cada 
tribo tem o foco em um ator. Por exemplo, no Gympass, onde 
tínhamos academias, RH das empresas e funcionários das 
empresas, tínhamos 3 tribos, cada uma focada nesses três atores 
do marketplace. Na Conta Azul tínhamos duas tribos focadas no 
dono do pequeno negócio e duas focadas no contador. Na Lopes 
desenhamos uma estrutura onde temos uma tribo focada no 
comprador de imóvel, outra no vendedor e uma terceira focada no 
corretor, que faz a intermediação. 


A vantagem desse modelo de organização é que o foco de cada 
time é bem definido, visando melhorar a experiência e resolver o 
problema de cada ator da plataforma. Caso a arquitetura de 
sistemas seja muito acoplada, pode haver bastante dependência 
entre os times. Outro ponto de atenção é que algumas jornadas 
podem ficar divididas entre duas tribos. Por exemplo, no Gympass 
existe a jornada de fazer check-in em uma academia, que acontece 
quando o usuário vai até a academia, faz o check-in e a recepção o 
valida. Em uma organização de time por tipo de usuário, tanto o time 
de academias quanto o de usuário são responsáveis por essa 
jornada e devem se coordenar para fazer mudanças nessa parte do 
produto. 


Por jornada 


Nesse modelo, os times sao organizados de acordo com cada 
jornada do usuario. Busca, compra, agendamento de aula e assim 
por diante sao jornadas pelas quais seu usuario pode passar ao 
usar o seu produto. Confesso que nunca vi um time 100% 
organizado por jornada, mas já vi times organizados por produto ou 
por tipo de usuário terem uma ou mais tribos focadas em alguma 
jornada. Por exemplo, na Conta Azul tínhamos um time chamado 
Hubble que cuidava da jornada do usuário até ele poder usar 
funcionalidades financeiras, cuidadas pelo Spartans e 
funcionalidades fiscais e contábeis, cuidadas pelo time 
Underground. No Gympass, além dos times de usuário, academia e 
RH da empresa, tínhamos um time, chamado de Cross Features, 
que cuidava do cadastro de cada um dos participantes do 
marketplace (usuários, academias e RHs) e de receber o 
pagamento feito por RHs e usuários, e por fazer o pagamento para 
as academias. Na Lopes, decidimos criar, além dos times para 
comprador, vendedor e corretor, um time chamado Leads, que cuida 
das interações entre comprador e corretor. Na Locaweb criamos o 
time de sistemas centrais, depois renomeado para enterprise 
applications, responsável pela central do cliente, onde o cliente da 
Locaweb pode ver e administrar todos os produtos contratados. 


A principal vantagem dessa estrutura é que o foco em uma jornada 
aumenta a chance de proporcionar uma ótima experiência naquela 
jornada específica. Por outro lado, normalmente um squad é 
suficiente para cuidar de uma jornada, então você pode acabar com 
muitas tribos de um só squad. 


Por objetivo 


A organização por objetivo significa que a tribo tem foco em um 
objetivo específico. Conversão, retenção, experiência de uso etc. 
Não conheço nenhum time 100% estruturado somente por objetivos. 
No Gympass usávamos esse modo de organização no time de 
usuário quando o dividimos em duas tribos, uma focada em 
crescimento, que tinha por objetivo garantir que os funcionários dos 


clientes baixassem o app, criassem a conta gratuita e se tornassem 
assinantes e a outra focada em experiência digital para garantir que 
os usuários utilizassem e tirassem o maior proveito possível do app, 
garantindo a satisfação e a retenção destes. 


Nesse tipo de organização, o principal benefício é o foco no lugar 
aonde você quer chegar, o objetivo. A desvantagem é que você 
pode ter dois squads com objetivos diferentes lidando com a mesma 
área do produto, o que pode causar uma experiência estranha para 
o usuário. Outra desvantagem é que, se a arquitetura de sistemas 
estiver muito acoplada, pode haver muita dependência entre as 
equipes. 


Prós Contras 
Produto e A parte do produto que é e Perde-se um pouco de perspectiva a(s) 
responsabilidade da tribo é bem clara. pessoa(s) para quem esse produto 


resolve problemas. 


Usuário e Foco de cada time é bem definido, e Caso a arquitetura de sistemas seja muito 
visando melhorar a experiência e acoplada, pode haver bastante 
resolver o problema de cada ator da dependência entre os times. 
plataforma. e Algumas jornadas podem ficar divididas 


entre duas tribos. 





Jornada e Foco em uma jornada aumenta a e Normalmente um squad é suficiente para 
chance de proporcionar uma ótima cuidar de uma jornada, então você pode 
experiência naquela jornada específica. acabar com muitas tribos de um só squad. 
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produto, o que pode causar uma 
experiência estranha para o usuário 

e Se a arquitetura de sistemas estiver muito 
acoplada, pode haver muita dependência 
entre as equipes. 


Figura 6.2: Prós e contras dos diferentes tipos de organização de times de 
desenvolvimento de produto 


Híbrida 


Essas diferentes formas de organizar times de produto podem ser 
usadas em conjunto, ou seja, não são exclusivas. Na verdade, 


nunca vi uma equipe de desenvolvimento de produto usando 
exclusivamente um tipo de organização. As equipes são 
estruturadas em organizações híbridas. Veja a seguir alguns 
exemplos de organização híbrida. 


Na Locaweb tínhamos times por produto (Hospedagem, Email 
Marketing, Cloud etc.) e um time focado na jornada do cliente 
(Central do Cliente) 


Cloud 


Cloud Server Pro 
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Figura 6.3: Times de produto da Locaweb 


Na Conta Azul usávamos organização por funcionalidade. Um time 
para gestão financeira do pequeno negócio (Spartans) e outro para 
gestão fiscal e contábil (Underground). Um para gestão fiscal, 
contábil e de folha dos clientes do contador (Area 42) e outro para 
gestão de clientes do contador (Babilônia). Também organizávamos 
por tipo de usuário (times focados no dono do negócio e no 
contador) e por jornada (Hubble). 
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Figura 6.4: Times de produto da Conta Azul 


No Gympass definimos os times por tipo de usuario (usuario final, 
academia e RH), mas também usamos a organização por jornada 
para criar o time de Cross Features, responsável pelo cadastro de 
cada um dos participantes do marketplace (usuários, academias e 
RHs), por receber o pagamento feito por RHs e usuários e por fazer 
o pagamento para as academias. E usamos também a organização 
por objetivos quando quebramos o time de usuário final em duas 
tribos, uma de crescimento e outra de experiência digital. 


End user End user Cross 
Growth Digital Features 
Experience 
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Enrollment Engagement Billing & Payment 
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Figura 6.5: Times de produto do Gympass 





Na Lopes também definimos os times por tipo de usuario (cliente 
final, incorporador & proprietario, corretor & franquia) e definimos 
uma tribo focado na jornada entre cliente e corretor, que chamamos 
de Leads. 
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Figura 6.6: Times de produto da Lopes 





É importante ressaltar que esses exemplos são da época em que 
trabalhei nessas empresas. Da mesma forma que a visão e 
estratégia de produto evoluem, a estrutura de times também deve 
evoluir. 


6.3 Organizando squads em um time de produto 


Essas formas de organização de times de produto servem tanto 
para definir a organização entre tribos, bem como a organização dos 
squads de uma tribo. Alguns exemplos: 


e Hospedagem de sites (Locaweb): dentro do time de 
hospedagem de sites da Locaweb tínhamos 3 squads, um 
focado em hospedagem Windows, outro em hospedagem Linux 
e um terceiro com foco no painel de controle de gestão da 
hospedagem. 


e Academias (Gympass): no time focado em academias do 
Gympass tínhamos um squad focado em APIs para integração 
com sistemas de gestão para integração de processo de check- 
in dos usuários e de reserva de aulas e outro squad focado na 
experiência do gestor da academia, para que ele pudesse ter 
acesso a relatórios e configurar como sua academia apareceria 
no app do usuário. 


e Financeiro (Conta Azul): no time focado em gestão financeira 
do Conta Azul, tínhamos um time focado em integração com os 
bancos para receber dados de extrato bancário dos clientes, um 
outro focado na interface de gestão financeira, com relatórios e 
sistema de categorização dos lançamentos do extrato e um 
terceiro focado em uma funcionalidade que tinha nome próprio, 
o Receba Fácil, sistema de emissão de boleto bancário. 


6.4 Times estruturais 


Times estruturais são os times que trabalham na estrutura 
necessária para os times de produto poderem fazer seu trabalho. 
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Figura 6.7: Times estruturais 


Alguns tipos de times estruturais necessários no desenvolvimento 
de produtos digitais: 


e SRE ou DevOps: SRE significa Site Reliability Engineering. 
Essa área, às vezes chamada de DevOps, é responsável pela 
infraestrutura onde o produto será hospedado e servido aos 
clientes. Responsável também por monitorar o produto e a 
infraestrutura de hospedagem para garantir que ele opere com 
a performance ideal. 


e Dados: aqui temos normalmente 3 disciplinas que precisam ser 
cuidadas pelo time de dados. Primeiro, é necessário um time de 
engenharia de dados que cuide da infraestrutura necessária 
para gestão dos dados da empresa. Em seguida, é necessário 
um time de análise de dados, responsável por gerar relatórios e 
dashboards com base nos dados e mostrando a performance 


do produto. Por fim, é interessante ter também um time de 
cientistas de dados capaz de tirar insights dos dados e 
eventualmente criar algoritmos de machine learning que 
possam evoluir a medida que mais dados sao coletados e 
analisados. 


Arquitetura/Ferramentas/Fundagao: time que ajuda os times 
de produto a definirem os padrões de arquitetura de software. 
Esse time também pode trabalhar em temas que são comuns a 
todos os times como, por exemplo, autenticação e autorização, 
e infraestrutura de APIs. 


Design Ops: time central de design que cuida de criar e manter 
o Design System, biblioteca de componentes e padrões de 
interação. Essa equipe também pode cuidar da eficiência 
operacional dos product designers, dando-lhes ferramentas, 
capacitando os gestores e líderes para avaliar o desempenho 
desses product designers e auxiliando no onboarding. Nesse 
time também podem ficar profissionais de user research e de 
UX writing. 


Segurança da Informação: responsável por todos os aspectos 
de segurança da informação, tais como LGPD, certificação PCI, 
certificação ISO 27001, políticas de BYOD (bring your own 
device) para permitir que os funcionários utilizem seus próprio 
devices para o trabalho. 


Sistemas Internos: responsável por cuidar dos sistemas de 
terceiros, tais como Google Suite, Office 365, Slack etc., bem 
como dos equipamentos da empresa. 


Engenharia de Vendas: essa area faz bastante sentido em 
empresas que desenvolvem produtos para outras empresas. E 
um time com conhecimento técnico capaz de discutir detalhes 
de implementação e integração do seu produto com os 
sistemas do cliente. 


e Serviços Profissionais: caso as necessidades de 
implementação e de integração do novo cliente fujam do 
padrão, ou o cliente não esteja preparado para fazer essa 
implementação ou integração, pode ser interessante ter um 
time de serviços profissionais que faça esse trabalho. O 
recomendado é que esse time seja bem enxuto e utilize 
terceiros conforme a demanda para fazer o trabalho de 
implementação e integração. 


e HRBP e contratação: como visto acima, times de produto e 
suas estruturas são complexos, com muito trabalho colaborativo 
e com estruturas matriciais. É essencial ter um time de RH por 
perto para ajudar na gestão do time, com dois focos. HRBP, ou 
Human Resources Business Partners ajuda no dia a dia dos 
times e líderes em todas as questões ligadas à RH. 
Contratação, no inglês talent acquisition é responsável por todo 
o processo de atração e contratação de pessoas para o time. 


6.5 Implementação 


A implementação da estrutura de produtos que foi desenhada pode 
acontecer de duas formas. Ou você está criando uma estrutura do 
zero, ou você está ajustando uma estrutura já existente. 


Criando uma nova estrutura 


Quando você cria uma estrutura do zero, você tem a oportunidade 
de crescer de acordo com as necessidades. Você pode começar 
com um único squad, depois criar o segundo e assim por diante. É 
importante você ter em mente aonde você deseja chegar com essa 
estrutura. Você terá times estruturais? Quais? Que times de produto 
você pretende ter? 


Recomendo também começar a montar esses times pelos seus 
líderes, para que eles possam ter a oportunidade de contratar e 
formar os times conforme suas necessidades, desde que alinhados 
com a visão que você desenhou. 


Mudando uma estrutura existente 


Quando você chega para liderar um time já formado, é importante 
ter clareza da visão de produto, da estrutura atual e das pessoas 
que fazem parte desse time. Você precisará fazer várias conversas 
para entender bem esses três aspectos antes de propor mudanças 
na estrutura atual. Assim que você desenhar uma primeira versão 
da sua proposta, apresente-a como trabalho em progresso para 
algumas pessoas para colher feedback e ir ajustando. 


Uma vez acordada a nova estrutura, coordene com as pessoas dos 
times para fazer a mudança. Pode ser que alguns times que serão 
mexidos estejam terminando de fazer algumas coisas, então é 
importante alinhar com essas tarefas pendentes para permitir uma 
transição mais suave da estrutura atual para a nova. 


6.6 Qual é a melhor proporção entre Eng, UX e 
PM? 


Podemos encontrar muitos artigos de diferentes equipes de 
desenvolvimento de produto ao redor do mundo mostrando 
benchmarks de relações Eng:PM e UX:PM. Há um artigo recente de 
Ken Norton, parceiro do Google Ventures e ex-líder de gestão de 
produto do Google e do Yahoo!, onde ele compartilha os resultados 
de uma pesquisa informal que fez no Twitter: 


"Uma maioria significativa dos tweets recomendou algo na faixa 
de 5 a 9 engenheiros para cada PM. Houve motivos pelos quais 
as pessoas recomendaram ter mais ou menos, mas entre 5 e 9 
parece ser o ideal. Pensando em minha própria experiência, 
minhas equipes de melhor desempenho também se 
enquadraram nessa faixa. 


Quando se trata de designers, prefiro uma proporção de 1:1 com 
PMs para equipes de produtos focadas no usuário. As equipes 
de produto funcionam melhor quando a tríade dedicada de PM, 
designer e líder de tecnologia forma o núcleo." 





Portanto, parece que a recomendação geral é de 5 a 9 engenheiros 
por PM e 1 UX por PM. Aqui, quando contabilizamos as pessoas de 
engenharia, devemos também considerar as pessoas dos times 
estruturais. 


Alguns números da vida real 


No Gympass, trabalhamos para aumentar o número de engenheiros 
por gestores de produto. Em nossos esforços para aumentar a 
equipe de 32 para 85 pessoas em 5 meses conseguimos aumentar 
a relação Eng:PM e também a relação UX:PM. Nosso plano era 
chegar ao final de 2019 com quase 200 pessoas em nossa equipe 
de desenvolvimento de produto, com ainda mais engenheiros por 
gerente de produto e um melhor equilíbrio entre designers de UX e 
gerentes de produto, como acabou acontecendo. 


Gympass (Jun/18) 


Gympass (Nov/18) 
Gympass (Dec/19) 





Figura 6.8: Gympass 


Todos os benchmarks são claros quando explicam que cada gestor 
de produto deve ser pareado com um UX, especialmente para 
produtos voltados para o cliente. No caso do Gympass, são 3 tipos 
diferentes de clientes (usuários finais, academias e clientes 
corporativos) o que reforça a necessidade de manter a proporção 
recomendada de 1 product designer por gerente de produto. 


Na Conta Azul já tinhamos uma boa relação Eng:PM quando entrei 
em agosto de 2016. No entanto, a relação UX:PM estava abaixo dos 
padrões de mercado. Principalmente levando em consideração que 
um dos 4 valores fundamentais da Conta Azul é entregar o "Uau" 
aos clientes. Por esse motivo, trabalhamos para aumentar a 
proporção de designers de experiência do usuário em relação aos 
gestores de produto para aumentar o "Uau" entregue aos clientes. 


ContaAzul (Oct/16) 
ContaAzul (Jul/18) 





Figura 6.9: Conta Azul 


Na Locaweb, muitos produtos que construimos eram para 
engenheiros de software. Hospedagem de sites, hospedagem de 
banco de dados, SMTP, Servidores cloud e servidores dedicados. 
Por isso, o numero de engenheiros por gestores de produto é maior 
que o da Conta Azul e do Gympass. É ainda maior do que o limite 


superior recomendado de 9 engenheiros por gestor de produto. No 
entanto, podemos ver um fato interessante na proporção de 
designer de UX por gestor de produto. Como visto nos números de 
agosto de 2015, uma proporção maior de Eng:PM força um aumento 
em UX:PM em comparação à proporção de 1:1 recomendada. 
Quando olhamos os números de julho de 2016, temos mais 
engenheiros por gestores de produto, chegando a quase 12 
Eng:PM, o que fez aumentar a proporção UX:PM para quase 2:1. 
Tivemos que colocar 2 designers de UX para cada gerente de 
produto para que eles pudessem lidar com todo o trabalho de 
discovery que precisava ser feito para que os engenheiros 
pudessem construir o produto certo. Considerando os engenheiros 
como responsáveis pelo delivery e UX e gestores de produto como 
discovery, isso nos mostra que tínhamos cerca de uma pessoa de 
discovery para cada 4 de delivery. 


Total] EnglPM] — UXIPM 





Locaweb (Aug/15) 109 
Locaweb (Jul/16) 100 


Figura 6.10: Locaweb 


Lei de Conway 


A Lei de Conway foi criada por Melvin Conway, cientista da 
computação americano, e publicada pela primeira vez em abril de 
1968, em uma revista de Tecnologia da Informação bastante 
conhecida na época chamada Datamation. A Lei de Conway diz 
que: 


LEI DE CONWAY 


Qualquer organização que desenvolve um sistema produzirá um 


sistema cuja estrutura é uma cópia da estrutura de comunicação 
da organização. 





Já vi situações em que um time de desenvolvimento de produto é 
organizado em paridade com as áreas de negócio, ou seja, um time 
é focado nas necessidades do atendimento ao cliente, outro é 
focado no time de vendas, outro é focado no financeiro, mais um 
focado no marketing, e assim por diante. Não recomendo esse tipo 
de estrutura, pois diminui o foco no cliente. 


Os estágios de Tuckman de evolução de times 


Bruce Tuckman, um pesquisador americano sobre dinâmica de 
grupos, propôs em 1965 quatro estágios pelos quais passa um 
grupo de pessoas que começam a trabalhar juntas, e como esses 
estágios impactam na eficácia desse grupo. 


Eficacia 


Performando 


Formando Normatizando 


Confrontando 





Tempo 


Figura 6.11: Os 4 estagios de Tuckman para formagao de times 


Formando (forming): nesse estagio, as pessoas do grupo 
estao se conhecendo, entendendo os objetivos comuns e 
buscando formas de trabalharem juntas. 

Confrontando (storming): em seguida, acontecem alguns 
confrontos, quando o grupo começa a discutir sobre como o 
trabalho será feito e começa a conhecer as habilidades de cada 
pessoa no grupo. 

Normatizando (norming): esse é o momento em que os 
membros do grupo definem o processo de trabalho e os papéis 
e responsabilidades de cada membro do time. Nessa fase os 
membros do time já se conhecem melhor e respeitam as 
habilidades uns dos outros. 

Performando (performing): é nesse momento que o time de 
fato começa a produzir e a entregar resultados. O time já se 


conhece bem, o processo de trabalho é claro e acordado entre 
todos os membros do time. 


Não há uma melhor forma de se estruturar um time de produto. Há 
aquela que faz mais sentido para a estratégia e objetivos definidos 
para atingir a visão de produto. Por isso, a estrutura de time não é 
escrita em pedra. Se houver necessidade, por mudança de objetivos 
ou de estratégia, pode fazer sentido mudar a estrutura do time. 
Contudo, não recomendo fazer isso com muita frequência, devido 
ao tempo necessário para um time recém-formado passar pelos 
estágios de Tuckman. Ouvi certas pessoas comentando que 
trabalham em empresas que mudavam a estrutura de time de 
desenvolvimento de produtos a cada 3 ou 6 meses. Não é tempo 
suficiente para passar pelos estágios de Tuckman. 


Unidades de negócio 


Em algumas situações, em vez de ter times de produto separados, 
mas dentro da mesma organização, pode ser interessante criar 
unidades de negócio razoavelmente independentes. Em unidades 
de negócio, temos não só um time de desenvolvimento produto 
separado, como todas as áreas necessárias para o negócio 
acontecer de forma independente tais como marketing, vendas, 
atendimento ao cliente etc. 


Na Locaweb optamos pelo modelo de unidades de negócio 
independentes quando adquirimos empresas. A Tray era uma 
empresa de soluções de ecommerce que passaram a fazer parte do 
portfólio de produtos da Locaweb. Como a Tray já operava como 
uma empresa independente, optamos por mantê-la dessa forma, 
somente tendo as áreas de administração, financeiro e RH em 
comum. Essa é uma maneira bem comum de criar áreas de 
negócio, por meio de aquisições de empresas. 


No Gympass vislumbramos a oportunidade de criar um novo 
produto chamado Gympass Wellness, que oferece serviços de bem- 
estar tais como aplicativos de atividade física, de nutrição e de 


meditação para os funcionários dos clientes do Gympass. Optamos 
por iniciar esse novo produto como uma unidade de negócios, com 
time de produto, de marketing e de vendas independente do 

Gympass, visando dar maior autonomia e agilidade para esse time. 


Na Lopes temos a CrediPronto, unidade de negócios que é uma 
joint-venture entre Lopes e Itaú para oferecer crédito para 
compradores de imóveis. Pelo fato de a natureza do negócio ser 
completamente diferente do negócio principal de transação 
imobiliária e ainda por ter um novo sócio, optou-se pelo modelo de 
unidade de negócio. 


6.7 O que faz um grupo de pessoas se comportar 
como um time? 


Não é suficiente organizar as pessoas na estrutura de equipes 
descrita aqui para que se comportem como uma equipe. Para que 
se percebam como uma equipe e passem a atuar como tal, 
precisam de objetivos comuns. 


Um problema muito comum que vejo nas equipes de 
desenvolvimento de produto é que, mesmo sendo muito bem 
organizados em tribos e esquadrões, com tribos estruturais e tribos 
de produtos, e as pessoas certas com as funções certas em cada 
equipe, os objetivos são definidos por função. Os gerentes de 
produto têm um conjunto de objetivos diferente dos de designers de 
produto, que são diferentes dos objetivos dos engenheiros. Isso 
simplesmente não funciona, porque cada pessoa se concentrará 
nos seus próprios objetivos. 


Se definirmos todos os objetivos como sendo comuns a todos os 
membros da equipe, todos eles trabalharão juntos para atingi-los. 
Mesmo que o objetivo pareça mais relacionado a um dos aspectos, 
como mais relacionado ao negócio (gerente de produto) ou à 


experiéncia do usuario, ou mais relacionado a engenharia, todos os 
membros da equipe devem ter os mesmos objetivos. 


Entao, a resposta curta para a pergunta "O que faz um grupo de 
pessoas se comportar como uma equipe?" são objetivos comuns. 


6.8 Resumindo 


e Times de desenvolvimento de produto são organizados em 
times mínimos, também chamados de squads, compostos de 
engenheiros, product designers e product managers. É 
importante deixar esses times o mais enxuto possível para 
ajudar em sua produtividade. Esses times mínimos são 
agrupados em times de produto chamados de tribos de 
produto. 


e Há 4 formas de se organizar os times de produto: por 
produto ou funcionalidade, por tipo de usuário, por jornada ou 
por objetivo. É possível também usar dois tipos diferentes de 
organização, criando uma organização híbrida. 


e Existem também as tribos estruturais, que criam a estrutura 
necessária para as tribos de produto performarem. Times que 
compõem as tribos estruturais são SRE/DevOps, Dados, 
Arquitetura/ Ferramentas/ Fundação, Design Ops, Segurança 
da Informação, Sistemas Internos, Engenharia de Vendas e 
Serviços Profissionais. 


e A implementação da organização de time desenhada pode ser 
feita ou criando uma nova estrutura ou ajustando um time já 
existente. Em ambas as situações é importante conhecer bem a 
visão e a estratégia de produto para desenhar e implementar 
uma estrutura de time alinhada com ela. 


e A proporção mais indicada entre pessoas em engenharia e 
gestores de produto é de 7 +/- 2 engenheiros para cada gestor 
de produto. E de um product designer para cada gestor de 
produto. 


e Dois conceitos importantes no desenho de sua estrutura de 
time são o da Lei de Conway, que diz que as organizações 
tendem a criar sistemas que são uma cópia da estrutura de 
comunicação das empresas, e os 4 estágios de Tuckman de 
formação de times, formando, confrontando, normatizando e 
performando. 


e É possível também organizar times de produto por unidades de 
negócio que tenham outras funções além das compreendidas 
em um time de desenvolvimento de produto, tais como 
marketing, vendas e atendimento ao cliente. As motivações 
para criar unidades de negócio em vez de times de produto 
podem ser devido à aquisição, ou para dar mais agilidade ao 
novo negócio ou mesmo por se tratar de uma nova linha de 
produto completamente diferente do produto original. 


e O que faz um grupo de pessoas se comportar como um time 
são os objetivos comuns. 


No próximo capítulo vamos ver um pouco mais sobre desenvolver o 
time e gerenciar expectativas. 


CAPITULO 7 
Desenvolvendo o time e gerenciando 
expectativas 


Como comentei no capitulo Papéis, responsabilidades e 
senioridade, além de definir e implementar a visão e a estratégia de 
produto, é responsabilidade da head de produto desenvolver seu 
time e gerir expectativas. Na terceira parte deste livro, sobre 
Ferramentas, vou falar sobre várias ferramentas úteis para ajudar a 
head de produto a cumprir com essas duas responsabilidades. 
Contudo, antes de falar dessas ferramentas, eu queria falar sobre 
três conceitos muito importantes para um head de produto. 


Como descrevi no livro Gestão de produtos: Como aumentar as 
chances de sucesso do seu software, as 7 principais características 
de um gestor de produtos são empatia, comunicação, gestão do 
tempo, novas tecnologias, habilidades empresariais, 
curiosidade aguçada e tema do produto. 


Como você deve imaginar, essas características também são 
fundamentais para um head de produto. Contudo, gostaria de 
destacar e relembrar 3 delas, por considerá-las essenciais para o 
dia a dia da pessoa head de produto: 


Empatia 


Empatia é a capacidade que uma pessoa tem de se colocar no lugar 
de outra para compreender suas expectativas. Seus anseios, 
motivações, necessidades e problemas. Essa característica é 
importante para entender os clientes e usuários do produto, saber 
como estes se relacionam com ele, e que problema esperam 
resolver ou que necessidade querem ver atendidas. Isso ajudará o 
gestor de produtos a entender melhor seu usuário para poder, junto 
com o UX e a engenharia, desenvolver o melhor produto. 





Figura 7.1: Empatia (fonte: http://www.rollingalpha.com/2015/07/21/poor-people-dont-think- 
like-rich-people/) 


Contudo, a empatia nao deve ser usada apenas com o cliente ou 
usuário. O gestor de produtos deve usá-la também no seu 
relacionamento com todas as áreas da empresa para ajudá-lo a 
entender quais são as expectativas que essas áreas têm em relação 
ao produto, e qual o impacto que seu produto tem no trabalho delas. 
Será que aumentaram os problemas jurídicos devido a alguma 
funcionalidade nova no produto? Qual o impacto para a equipe de 
vendas, suporte, operações, financeiro e marketing? Até mesmo em 
relação ao time do produto, engenheiros e designers de UX, como o 
produto interfere no trabalho desses profissionais? 


Empatia também é muito importante para que a head de produto 

possa entender como ela pode ajudar seu time a se desenvolver. 

Qual das 7 características citadas acima precisa de mais atenção 
nesse momento e por quê? Qual é a melhor forma de ajudar essa 
pessoa a desenvolver essa habilidade? 


A head de produto também precisa se colocar no lugar dos donos 
do produto para entender suas expectativas sobre o produto e os 
resultados que ele trará para a empresa. 


Comunicação 


A capacidade de se comunicar é fundamental para que a head de 
produtos possa gerir expectativas e ajudar seu time a se 
desenvolver. A head de produtos precisa se comunicar com as 
pessoas nos mais diferentes cenários: em conversas um a um e em 
pequenos grupos, ou fazendo apresentações para grupos pequenos 
e grandes de pessoas, apresentações que podem ser internas 
(dentro da empresa) ou externas (em conferências, grupos de 
usuários etc.). 


Deve também ser boa de comunicação escrita (e-mail, blog, 
documentação, chat, redes sociais etc.), e ser capaz de discernir 
sobre qual a forma de comunicação mais apropriada para cada 
momento, público e meio de comunicação; e de se comunicar de 
forma a ser entendido pelos diferentes públicos: técnico e não 
técnico. Como se isso tudo não bastasse, essa pessoa também 
precisa ser capaz de se comunicar passando segurança e confiança 
no que está comunicando; afinal, head de produtos não só é o 
porta-voz do produto como também é a referência mais sênior de 
toda a empresa sobre o produto. 


É importante lembrar que comunicação é uma via de mão dupla, ou 
seja, a head de produtos tem de ser muito boa em saber ouvir e 
compreender o que os outros estão dizendo, e entender os anseios 
e as necessidades deles; o que tem a ver com a primeira 
característica, a empatia. 


Habilidades empresariais 
O gestor de produtos deve se preocupar se o seu produto está 


atingindo os objetivos de negócio, pois o atingimento - ou não - é a 
principal fonte de expectativas das pessoas em relação ao produto. 


Como o produto vai ajudar a atingir os objetivos de negócio? Se o 
objetivo for margem, a receita e os custos estão sob controle? Se o 
objetivo for só receita, como está o crescimento dela”? Se o objetivo 
for número de usuários, como essa métrica está evoluindo? 


Além disso, o gestor de produtos deve entender como cada área da 
empresa funciona e como o produto afeta essas áreas. Como o 
jurídico funciona? Como o produto impacta no departamento 
jurídico? E como o departamento jurídico impacta no produto? 
Essas perguntas podem ser repetidas para todas as áreas da 
empresa: suporte, operações, financeiro, RH, marketing, vendas, 
engenharia e UX. 


7.1 Resumindo 


e Para desenvolver seu time e gerir expectativas, o head de 
produto deve ter as 7 características de um bom gestor de 
produtos: empatia, comunicação, gestão do tempo, novas 
tecnologias, habilidades empresariais, curiosidade 
aguçada e tema do produto 


e Três dessas características são essenciais para o trabalho de 
head de produto. Empatia para entender de onde vêm as 
expectativas e que elementos precisam ser desenvolvidos em 
seu time. Comunicação para poder entender e se fazer 
entender quando estiver conversando com as pessoas da 
empresa para gerir suas expectativas e quando estiver 
desenvolvendo seu time. Habilidades empresariais que 
ajudarão a entender os objetivos da empresa que são 
componentes importantes das expectativas que as pessoas têm 
em relação ao produto. 


No próximo capítulo vamos ver os antipadrões de liderança de times 
de desenvolvimento de produto. 


CAPITULO 8 
Antipadroes 


Um antipadrão é uma resposta comum mas ineficaz e 
contraproducente a um problema. Esse termo foi criado por Andrew 
Koenig em 1995, inspirado no livro de 1994, Design Patterns: 
Elements of Reusable Object-Oriented Software (Padrões de 
design: Elementos reutilizáveis de software orientado a objetos) 
escrito por Gamma Erich, Helm Richard, Johnson Ralph e Vlissides 
John, que lista uma série de padrões de design de desenvolvimento 
de software que seus autores consideraram simples, sucintos e 
eficazes para os problemas mais comuns. 


Mas o termo foi popularizado pelo livro AntiPatterns: Refactoring 
Software, Architectures, and Projects in Crisis (Antipadrões: 
Refatorando software, arquiteturas e projetos em crise), de 1998, 
escrito por Raphael Malveau, William Brown, Hays McCormick e 
Thomas Mowbray, que estendeu seu uso além do campo do design 
de software para se referir informalmente a qualquer solução ruim 
para um problema. 


Na Wikipedia em inglês, o termo lista mais de 70 antipadrões. Vou 
listar a seguir os antipadrões que encontrei com mais frequência na 
minha carreira. Esses antipadrões que cito acontecem quando a 
liderança da empresa não tem experiência suficiente em 
desenvolvimento de produtos e é assessorada por pessoas que 
foram bem-sucedidas em gestão de desenvolvimento de software 
no passado, mas que não se atualizaram. 


Como expliquei na introdução, desenvolvimento de software é uma 
ciência muito nova, especialmente se comparamos com outras 
ciências como astronomia, medicina, matemática, química etc. A 
primeira vez que um computador armazenou um software em 
memória e o executou com sucesso foi às 11 horas do dia 21 de 
junho de 1948, na Universidade de Manchester, no computador 


Manchester Baby. Isso significa que desenvolvimento de produtos 
de software esta engatinhando. Se um profissional nao se mantiver 
atualizado, o conhecimento e experiéncia que o fez bem-sucedido 
no passado pode não ser o mais adequado para fazê-lo bem- 
sucedido no futuro. 


8.1 Documentação 


Uso excessivo de documentação vai sem dúvida desacelerar o time 
de desenvolvimento de produtos. Não é à toa que no Manifesto Ágil, 
escrito em 2001, dizemos que valorizamos "Software em 
funcionamento mais que documentação abrangente”. Para certos 
líderes chega a ser mais importante que o próprio produto. Nada 
pode ir para produção se não estiver devidamente documentado. 


A última vez que escrevi um PRD (Product Requirement Document 
ou Documento de Requisitos de Produto) foi em 2005, logo quando 
eu entrei na Locaweb. Foi um trabalho bastante demorado, onde 
documentei em detalhes tudo o que precisávamos implementar no 
software. Passada para a engenharia, a implementação foi feita com 
vários erros porque os engenheiros acabaram não entendendo o 
que estava escrito em algumas partes e decidiram implementar 
como acharam melhor. A partir disso passamos a diminuir o uso de 
documentação extensa e aumentamos a interação entre gestores de 
produto, designers de produto e engenheiros. 


Marty Cagan tem um artigo muito bacana chamado How to write a 
good PRD (Como escrever um bom PRD - 
https://svpg.com/assets/Files/goodprd.pdf) onde ele comenta logo 
no começo: 


"Forneço este documento aqui principalmente para fins 
históricos. Foi escrito em 2005 para refletir melhores práticas 
das décadas anteriores. 


Não tenho defendido o uso de PRDs por muitos anos, 


começando aproximadamente em 2007. Não é que os PRDs 
sejam tão ruins. Contudo, se o gerente de produto está gastando 
seu tempo escrevendo o PRD, então é improvável que ele ou ela 
esteja fazendo o trabalho real de discovery de produto." 





Padrão recomendado: é só seguir o manifesto ágil, produto na 
mão de clientes traz mais valor para os clientes e para a empresa 
do que documentação abrangente e detalhada. 


8.2 Foco em dados 


Acontece quando o head de produtos e outros líderes só tomam 
decisões se houver abundância de dados, relatórios, gráficos. Há 
dois perigos com esse antipadrão: 


e Tempo: às vezes para juntar todos os dados necessários leva- 
se muito tempo. É a situação conhecida como analysis 
paralysis ou paralisia da análise. Nada acontece enquanto os 
dados não são meticulosamente obtidos e analisados. Muitas 
vezes, após uma primeira análise, mais dados são pedidos e 
mais tempo é investido na busca desses novos dados, e esse 
ciclo pode se repetir por inúmeras vezes. E, enquanto esse 
ciclo se repete, nenhuma decisão é feita. Daí a paralisia da 
análise. 


TIME COST 


STRATEGY A 


STRATEGY B 


ANALYZING WHETHER 
STRATEGY A OR B 
IS MORE EFFICIENT 


THE REASON T AM SO INEFFICIENT 


Figura 8.1: O custo da análise (fonte: https://xkcd.com/1445) 





e Erros: quando confiamos somente e exclusivamente nos 
dados, há grandes chances de incorrermos em erros. Como 
podemos ter certeza de que temos todos os dados necessários 
para concluir algo? Como podemos ter certeza de que os dados 
estão corretos? É comum ouvir que as decisões devem ser 
data-driven, ou seja, baseadas em dados. Contudo, os dados 
podem estar incorretos e/ou ser insuficientes para descrever 
uma determinada situação. Pensando nisso, mais recentemente 
surgiu o conceito de decisões data-informed, ou seja, que são 
baseadas em dados, mas não somente em dados. Levam em 
conta, além dos dados, informações qualitativas, experiência 
prévia e intuição. 


Padrão recomendado: procure tomar decisões com dados, mas 
sempre entendendo que os dados são incompletos, e leve sempre 
em consideração informações qualitativas, experiência prévia e 
intuição. 


8.3 Grande reescrita 


Toda empresa tem um sistema legado. Mesmo a startup que acabou 
de ser criada, em poucos meses, podera olhar para sua base codigo 
como legado e algo que precisa ser melhorado. Nesse momento 
aparecem frases como: 


e Está cada vez mais difícil mexer no código. 

e Se fosse fazer do zero, seria muito mais rápido. 

e Se não reescrevermos, vai ficar cada vez mais lento e perigoso 
mexer no código. 


E nesse momento nasce a grande solução da reescrita. E essa 
grande reescrita vai, em algum momento causar aquele 
congelamento de evolução do produto. Por que escrever algo para o 
legado, se o novo sistema vai substituí-lo? E tem também a 
migração ou transição. Como vamos do sistema legado para o 
novo? 


Normalmente nas estimativas iniciais a reescrita vai levar uns 2 ou 3 
meses e quando avançamos percebemos que vai ser um pouco 
mais longo, podendo levar anos. Na Locaweb tomamos a decisão 
de reescrever o sistema central que tinha o cadastro de clientes e 
fazia a cobrança. O projeto original era de 9 meses e acabou 
levando mais de dois anos. Além disso, quando o novo sistema 
entrou, nossa cobrança de clientes não funcionou durante uns 2 
meses e ficou mais uns 6 meses rodando de forma incorreta até 
terminarmos todos os ajustes necessários. Ou seja, a reescrita que 
originalmente levaria 9 meses acabou levando 3 anos. 


Padrão recomendado: evite grandes reescritas a todo o custo. Na 
grande maioria das vezes haverá formas de substituir o sistema 
legado de forma gradual e progressiva, sem causar disrupções para 
a empresa e para os clientes. 


8.4 Lista de desejos 


Quando uma nova head de produto se junta a uma nova empresa, é 
comum durante o processo de onboarding, durantes as inumeras 
conversas com pessoas de varias areas da empresa, ouvir uma 
série de pedidos e de reclamações em relação ao produto de que 
essa nova head vai cuidar. Para "marcar pontos" com essas 
pessoas, que eventualmente vão dar feedback sobre seu trabalho, 
pode ser tentador construir sua lista do que fazer baseado nesses 
pedidos e problemas reportados. É a "lista de desejos" da empresa. 
Em seguida, essa head de produto vai priorizar essa lista ou até 
mesmo terceirizar essa priorização para algum líder da área de 
vendas ou de negócios da empresa. Já vi situações em que o head 
de produto coletava a "lista de desejos" e apresentava em uma 
reunião com líderes de várias áreas da empresa, dizendo “agora 
preciso que vocês priorizem o que querem que o time de 
desenvolvimento de produto faça primeiro”. 


Apesar de ser algo tentador, pois a "lista de desejos” vai de fato 
ajudar o head de produto a marcar pontos com líderes das outras 
áreas, esse comportamento fará com que o time de 
desenvolvimento de produto se torne um mero cumpridor de ordens, 
inibindo o potencial de inovação que ele pode trazer para o negócio. 
Quando o head de produto foca o time em atender a "lista de 
desejos", acaba focando o time em ser um implementador de 
soluções que são dadas por outras pessoas, tirando o foco dos 
problemas a serem resolvidos. É a diferença entre o time 
implementador de soluções que já vêm prontas das outras áreas da 
empresa versus um time focado em encontrar as melhores soluções 
para resolver problemas da empresa. Vou falar mais desse assunto 
na próxima parte do livro, sobre princípios. 


Padrão recomendado: time de desenvolvimento de produto 
trabalham em entender problemas para depois avaliar soluções 
possíveis. Procure então descobrir a lista de problemas a trabalhar, 


e nao a lista de coisas que as outras areas querem que o time de 
desenvolvimento de produto faça. 


8.5 Resumindo 


e Antipadrões são respostas comuns mas ineficazes de se 
resolver problemas. Existem muitos antipadrões bem 
documentados no mundo do desenvolvimento de produtos 
digitais. Os 4 antipadrões mais comuns em liderança de 
desenvolvimento de produto são documentação, foco em 
dados, grande reescrita e lista de desejos. 


e Documentação, que deveria ser mantida em um mínimo, para 
certos líderes chega a ser mais importante que o próprio 
produto. Nada pode ir para produção se não estiver 
devidamente documentado. 


e Foco em dados é quando toda e qualquer decisão tem que ser 
tomada com dados, sem levar em conta informações 
qualitativas, experiência prévia e intuição. 


e Grande reescrita acontece quando uma nova head de produto 
encontra um sistema escrito há algum tempo e identifica que 
será melhor reescrever do zero um novo sistema do que 
aprimorar o atual. 


e Lista de desejos vem da necessidade de o novo head de 
produtos de agradar a todos os stakeholders, focando o time de 
desenvolvimento de produtos a apenas implementar o que é 
pedido, delegando a priorização para as outras áreas da 
empresa. 


Com este capítulo terminamos a parte 1 sobre os conceitos 
necessários para entender os papéis e responsabilidades de um 


head de produtos. Na proxima parte vamos ver quais principios 
devem nortear o trabalho de uma head de produto e de seu time. 


Principios 

p 
Toda empresa possui sua propria cultura e, dentro de cada 
empresa, todo departamento também possui sua própria cultura. 
Além disso, cada pessoa tem seus princípios e valores que norteiam 
seus passos pela vida. Aqui vou falar sobre a cultura, os valores e 
os princípios que acredito serem obrigatórios para criar produtos 
digitais de sucesso. E também, quais são os 4 principais valores que 
toda equipe de desenvolvimento de produtos e, consequentemente, 
toda empresa que tenha times de desenvolvimento de produtos 
digitais deve ter. 


CAPÍTULO 9 
Pessoas: prioridade nº 1, sempre 


Vou começar esta parte do livro compartilhando meus princípios 
pessoas de liderança. Serão cinco: 


e Pessoas: a prioridade nº 1, sempre 
e Liderar é como ser um médico 

e Liderando sob pressão 

e Mentoria é uma via de mão dupla 

e Como e quando delegar 


Falarei desses princípios ao longo deste e dos próximos capítulos, a 
começar pelo princípio de que pessoas são a prioridade nº 1, 
sempre. 


Muitas vezes vejo empresas afirmando que a valorização da 
empresa, a receita, o crescimento, o lucro, o número de clientes, ou 
a satisfação do cliente é sua prioridade número 1. Todas são boas 
prioridades e cada uma é apropriada para contextos específicos em 
que uma empresa pode estar. No entanto, eu argumento que elas 
devem ser prioridade número 2, 3, 4 e assim por diante, porque 
nossa prioridade número 1 deve sempre ser as pessoas que fazem 
parte nossa equipe. Sem as pessoas que trabalham conosco, será 


muito dificil, se nao impossivel, atingir qualquer outro objetivo que 
tenhamos. 


Gastamos dinheiro e energia atraindo as melhores pessoas e 
convencendo-as a se unirem a nossa empresa para construir o que 
pretendemos construir para atingir a meta que estabelecemos. 
Pagamos a elas para estarem conosco durante todo o processo de 
construção e normalmente ficamos chateados quando perdemos 
pessoas da nossa equipe, especialmente se elas estiverem 
realmente engajadas e alinhadas com nossos objetivos. Portanto, as 
pessoas da nossa equipe são como clientes, gastamos dinheiro e 
energia para adquiri-las e retê-las. Mas elas são ainda mais 
importantes do que nossos clientes, porque sem a nossa equipe, 
não há como sermos capazes de lidar com nossos clientes e 
alcançar nossos objetivos. 


Isso não significa que precisamos ser "bonzinhos" com nossa 
equipe, ou que devemos dar tudo o que eles pedem. O que 
precisamos fazer é equilibrar as pressões externas e internas para 
que as pessoas possam melhorar continuamente. Se a pressão 
externa estiver aumentando, precisamos criar o ambiente e fornecer 
as ferramentas para que as pessoas fiquem mais motivadas, 
tenham mais drive e aumentem sua força interior. E se temos 
pessoas ou equipes com excesso de motivação e de energia, 
precisamos dar a elas mais responsabilidades e objetivos mais 
elevados. No capítulo Liderando sob pressão vou falar mais sobre 
esse equilíbrio. 


9.1 Maçãs podres 


O termo maçã podre, apesar de bastante forte, serve para descrever 
uma situação bastante delicada na formação e gerenciamento de 
times. Chamamos de maçã podre a pessoa que destoa 


negativamente do resto do time e que, com seu comportamento, 
podera estragar a equipe. 


A InfoQ (https://www.infoq.com/news/2009/01/handling-your- 
underperformer/) falou bastante sobre esse tema da maga podre do 
ponto de vista técnico, o under-performer, aquele que é ou esta 
tecnicamente abaixo do resto da equipe e mostrou como o time 
pode ajudar essa pessoa a melhorar. 


Agora, O que fazer quando nos deparamos com uma maçã podre do 
ponto de vista comportamental? Alguém que é tecnicamente bom, 
mas que tem problemas de comportamento”? Tecnicamente essa 
pessoa pode ter bastante para contribuir para o time mas seu 
comportamento faz com que o time não consiga ter um bom 
relacionamento com essa pessoa. 


Nesses casos há dois caminhos a seguir: 


e O mais simples é tirar essa pessoa do time. Essa é uma 
solução fácil tanto para o time quanto para o seu líder. A 
tendência numa situação dessas é o time isolar a pessoa difícil 
até que ela, por vontade própria ou por decisão do chefe, saia 
do time. 


e O caminho mais difícil, mas que certamente trará mais 
benefícios para a equipe, é ajudar essa pessoa difícil a se 
integrar ao time ao ponto de ela deixar de ser uma maçã podre. 


É fácil receber no time pessoas fáceis de lidar. O desafio é receber 
uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do 
time devem ser mais fortes que os valores da pessoa difícil ao ponto 
de os valores do time serem absorvidos e assumidos pela pessoa 
difícil. 


Conversas francas com todo o time e com a pessoa difícil são um 
bom caminho. A transparência é essencial. Se houver boa vontade 
e disposição tanto do time quanto da "maga podre”, há boas 
chances de a situação ser revertida. 


Vale lembrar que, na maioria das vezes, uma maga podre nao quer 
ser maçã podre. Ele pode não se dar conta de que seu 
comportamento é prejudicial para o time. Ele pode ter tido 
experiências anteriores onde seu comportamento seria considerado 
normal. Por isso vale investir em ajudar o time e a pessoa difícil a se 
entenderem. Contudo, não dá para tentar indefinidamente fazer com 
que as coisas se ajeitem. É importante definir um prazo para 
reavaliar a situação e, caso ela não tenha se resolvido, talvez não 
haja outra opção a não ser tomar uma decisão mais difícil: dispensar 
uma ou mais pessoas do time. 


9.2 Resumindo 


e As pessoas são, e devem ser sempre, a prioridade número 
1 de qualquer empresa. Gastamos dinheiro e energia para 
adquirir e reter as melhores pessoas. Ter as pessoas como a 
prioridade número 1 é a chave para atingir qualquer outro 
objetivo. Isso não significa ser "bonzinho", dando tudo o que 
elas querem, e sim que devemos ser capazes de equilibrar os 
desafios que damos às pessoas para que possam melhorar 
continuamente. 


e À pessoas maçãs podres podem drenar e prejudicar seu time. 
Você deve ajudar essas pessoas a se encaixarem em seu time 
e, se isso não for possível, você deverá tomar a decisão mais 
difícil: tirá-la do time. 


No próximo capítulo vamos entender como deve ser o trabalho de 
um líder por meio da analogia de que liderar é como ser um médico. 


CAPITULO 10 
Liderar é como ser um médico 


Em fevereiro de 2011 fui submetido a uma cirurgia de substituição 
de disco da coluna cervical. O médico fez a cirurgia no dia 25 de 
fevereiro. No entanto, o processo de cicatrização levou meses. 
Segundo o médico, poderia demorar um ano até que todos os 
sintomas que motivaram a cirurgia desaparecessem. 


O que me chamou a atenção é que o cirurgião só faz uma 
intervenção, mas todo o processo de cicatrização é feito pelo corpo. 
O mesmo acontece quando um médico prescreve um remédio, que 
também é uma intervenção, mas, novamente, cabe ao corpo todo o 
processo de cura. 


Liderar uma equipe é bastante semelhante. O líder deve fazer 
algumas intervenções quando necessário, mas cabe à equipe fazer 
o trabalho para atingir os objetivos. 


10.1 Liderança ágil 


Em uma das minhas leituras sobre liderança, encontrei uma 
comparação interessante entre liderança e jardinagem feita por 
Jurgen Appelo, autor do livro Management 3.0: Leading Agile 
Developers, Developing Agile Leaders: 


"Costumo comparar gestores a jardineiros. Um jardim não 
cuidado é normalmente cheio de ervas daninhas, não de beleza. 
De uma perspectiva biológica, não há diferença. De qualquer 
forma, o ecossistema no jardim é auto-organizado. É preciso um 


jardineiro (autorizado pelos proprietários do jardim) para 
transformar um jardim anarquista em algo que os proprietários 
vão desfrutar. Da mesma forma, é necessário um gestor 
(autorizado pelos acionistas) para conduzir as equipes auto- 
organizadas em uma direção que agregue valor aos acionistas." 





Mesmo que eu goste dessa comparação, ela considera que o 
jardineiro/gestor deve interferir constantemente, o que não acredito 
ser um comportamento adequado para um gestor. Na minha 
opinião, a interferência de um gestor deve ser feita apenas quando 
necessária e, após a interferência, a equipe deve trabalhar por si 
mesma para resolver as coisas com pouca ou nenhuma intervenção 
desse gestor. Daí a minha comparação com uma médica que 
interfere apenas quando necessário, prescrevendo mudança de 
hábitos, remédios, fisioterapia e/ou cirurgia e que deixa o corpo 
fazer o trabalho e se responsabilizar pelo processo de cura. 


10.2 Resumindo 


e Da próxima vez que você estiver em uma equipe, seja como 
parte dela ou desempenhando o papel de liderar a equipe, 
pense no papel de liderança semelhante ao do médico e no 
trabalho em equipe semelhante ao processo de cura realizado 
pelo corpo. Ajuda a entender as funções e responsabilidades do 
líder e das pessoas do time. 


No próximo capítulo vamos entender como liderar sob pressão. 


CAPITULO 11 
Liderando sob pressao 


Não existe um ambiente de trabalho sem pressão. Não conheço 
nenhum local de trabalho em que as pessoas digam que as metas 
são fáceis, que não há riscos em entregar a meta ou que o projeto 
será entregue no prazo com 100% de confiança. Se a empresa está 
crescendo rapidamente, as pessoas precisam sustentar ou melhorar 
essa taxa de crescimento. Se a empresa está em crise, precisam 
tirar a empresa da crise. 


E isso é bom! Na verdade, esta é a única maneira de fazer as 
coisas! As pessoas precisam de pressão para fazer as coisas. 


O que os líderes precisam saber sobre pressão? Toda gente, 
incluindo líderes e as pessoas que elas lideram, recebe pressão de 
fora (o objetivo, a data prevista, a falta de recursos), bem como de 
dentro (motivação, determinação, força interior). 


11.1 Pense em pessoas e equipes como balões 


Uma boa analogia que eu gosto de usar, especialmente quando a 
pressão externa aumenta, é que pessoas e equipes são 
semelhantes a balões. Precisamos equilibrar a pressão exterior com 
a pressão interior, com alguma tendência a ter um pouco mais de 
pressão do lado de fora para garantir o melhor desempenho. Se 
colocarmos muita pressão do lado de fora, sem fornecer às pessoas 
as ferramentas necessárias para aumentar a pressão interna, o 
balão explodirá, ou seja, o desempenho diminuirá, as pessoas 
ficarão incomodadas, às vezes até ficarão doentes (burnout) e 
provavelmente deixarão a empresa. 


As vezes, podemos ver algum aumento no desempenho logo após 
um aumento exagerado de pressão externa, mas não devemos nos 
enganar com esses resultados iniciais. Eles não serão sustentáveis 
se a pressão interna não for aumentada. Esse aumento no 
desempenho durará alguns dias e o desempenho diminuirá para 
níveis ainda menores do que quando aumentamos a pressão 
externa. 


Como podemos melhorar a pressão interna? Ninguém pode 
impactar diretamente a pressão interna de ninguém. Isso só pode 
ser feito indiretamente. Aqui estão algumas ferramentas: 


e Precisamos contratar pessoas com a motivação certa, drive e 
força interior, e devemos criar o ambiente para que elas possam 
manter tanto a motivação, como o drive e a força interior 
corretos. Pense em alinhamento de objetivos, visão, valores, 
cultura e incentivos financeiros e não financeiros. 

e Devemos apoiar o equilíbrio certo entre momentos com pressão 
e sem pressão. Podemos fazer isso incentivando as pessoas a 
se afastarem da pressão no local de trabalho e a fazerem 
outras coisas que gostam, como exercícios, ioga, meditação, 
música, leitura, passar tempo com seus entes queridos, 
cozinhar, festejar etc. Por outro lado, devemos evitar trabalhar 
longas horas, durante a noite, nos finais de semana e feriados. 
Note que que trabalhar longas horas é uma tática que pode e 
deve ser usada, mas somente quando necessário. Se isso se 
torna a norma, e não a exceção, não estamos apoiando o 
equilíbrio correto entre momentos com pressão e sem pressão. 


A analogia do balão funciona tanto para indivíduos quanto para 
equipes. Muita pressão sobre uma equipe sem a pressão interna 
apropriada fará o balão explodir. No caso de uma equipe, ela 
começará a apresentar um mau funcionamento, os membros da 
equipe começarão a apontar dedos uns para os outros e o 
desempenho cairá. Para aumentar a pressão interna de uma equipe 
e ajudá-los a lidar com o aumento da pressão externa, precisamos 
criar um ambiente que promova a criação de vínculos mais fortes 


entre os membros da equipe para que eles sejam mais eficazes em 
responder a pressao externa, sendo mais resilientes e mais 
adaptativos ao mesmo tempo. Respostas mais eficazes a pressao 
externa exigem uma combinação de resiliência e adaptação. 


Essa analogia também é boa para explicar por que as melhores 
pessoas decidem deixar uma companhia. Podemos pensar nessa 
situação como se houvesse mais pressão interna do que pressão 
externa. Se uma pessoa ou uma equipe tem mais motivação, drive e 
força interior do que aquilo que o líder lhe pede ou a estratégia da 
empresa exige dela, ela inflará o balão até ele explodir. Então elas 
vão deixar a empresa. Lembre da prioridade nº1: pessoas, sempre. 


11.2 Resumindo 


e Não existe um ambiente de trabalho sem pressão. Pessoas e 
equipes precisam da pressão externa (a meta, a data prevista, 
a falta de recursos) e também de dentro (motivação, drive, força 
interior) para existir e fazer as coisas, como um balão. 


e À pressão interna e a pressão externa precisam ser 
balanceadas com alguma tendência a ter um pouco mais de 
pressão do lado de fora para ter melhoria contínua. 


e Sob pressão, uma pessoa e uma equipe explodem ou ficam 
mais fortes. É papel do líder ajudar a pessoa ou a equipe a 
perceber isso e trabalhar em conjunto com eles para apoiar o 
aumento da pressão interna. 


No próximo capítulo falarei sobre mentoria. 


CAPITULO 12 
Mentoria é uma via de mão dupla 


A mentoria é uma das responsabilidades mais importantes de um 
head de produto: ajudar sua equipe a se desenvolver. Como ja 
disse, entre 10% a 40% do tempo do head de produto deve ser 
focado em ajudar as pessoas de sua equipe a se desenvolverem. 
Quem me conhece sabe que gosto de termos claramente definidos, 
então aqui está a definição de mentoreamento da Wikipedia: 


"A mentoria é um processo de transmissão informal de 
conhecimento, capital social e apoio psicossocial percebido pelo 
receptor como relevante para o trabalho, carreira ou 
desenvolvimento profissional; mentoria envolve comunicação 


informal, geralmente face a face e durante um período, entre 
uma pessoa que é percebida como tendo maior conhecimento, 
sabedoria ou experiência relevante (a mentora) e uma pessoa 
que é percebida como tendo menos (a mentorada)”. 





A partir dessa definição, fica clara a natureza unidirecional da 
mentoria, ou seja, o conhecimento flui da pessoa "mentora" para a 
“mentorada”. 


Recebi e dei orientação durante toda a minha carreira. Mesmo 
quando era estudante, dava e recebia orientação. Eu acho que 
alguém recebe orientação desde que nasce. Desde o início da 
minha carreira, tive a oportunidade de dar orientação às pessoas 
que lidero e, mais recentemente, tenho sido convidado a orientar 
empresários e gestores de produto para ajudá-los nas próximas 
etapas de seus empreendimentos e de suas carreiras. Fico muito 
feliz em saber que posso ajudar alguém compartilhando minha 
experiência. 


Uma via de mão dupla 


No entanto, minha experiéncia como mentor me mostrou que a 
definição da Wikipedia está incompleta. Wikipedia define mentoria 
como transmissão de conhecimento. Meu entendimento é que a 
mentoria é mais do que uma transmissão de conhecimento. É uma 
troca de conhecimento. Mesmo considerando que uma das pessoas 
envolvidas no processo de mentoria é mais experiente em 
determinado aspecto, tópico ou área, a outra pessoa pode ter 
experiência e conhecimento em outro aspecto, tópico ou área que 
pode trazer novos insights. Ou a outra pessoa pode usar sua 
novidade no tema em que está recebendo mentoria para trazer uma 
nova perspectiva que o mentor não percebeu. 


Portanto, da próxima vez que você estiver em uma situação de 
mentoria, especialmente se estiver na posição de mentor, pense 
nisso como uma troca de conhecimento, capital social e apoio 
psicossocial relevante, útil e valioso tanto para o mentorado quanto 
para o mentor. Tenho a impressão de que você vai gostar ainda 
mais de sua próxima sessão de mentoria. 


12.1 Resumindo 


e Mentoria é um dos papéis mais importantes de um head de 
produto. E através da mentoria que um head de produtos ajuda 
seu time a se desenvolver. 


e Mentoria é uma via de mão dupla. A pessoa no papel de 
mentora deve estar aberta a novos aprendizados vindos de 
suas sessões de mentoria com sua mentorada. 


No próximo capítulo vamos entender um pouco mais sobre cultura, 
quais valores são essenciais para uma empresa ter produtos de 
sucesso e o papel do head de produto na criação e manutenção da 
cultura da empresa. 


CAPITULO 13 
Como e quando delegar 


Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a 
alguém, normalmente com menos senioridade do que a pessoa que 
está executando o ato de delegar. A liderança é um ato contínuo de 
delegação de tarefas e de responsabilidades. Parece um ato 
bastante simples mas tem vários aspectos importantes a serem 
considerados para aumentar as chances de sucesso. 


Jurgen Appelo, autor do já mencionado livro Management 3.0: 
Leading Agile Developers, Developing Agile Leaders, comenta que 
delegar não é uma decisão binária em que você delega ou não 
delega. Existem outros níveis de delegação entre esses dois 
extremos e cada um desses outros níveis deve ser usado 
dependendo do contexto, ou seja, do problema a ser resolvido e de 
quem vai trabalhar nele. Segundo ele, são sete níveis: 


e Dizer: você toma decisões e as anuncia ao seu time. Na 
verdade, isso não é delegação. (= 

e Vender: você toma decisões, mas tenta "vender" sua ideia para 
sua equipe. 

e Consultar: você convida seu time para comentar e pondera 
suas contribuições. 

e Concordar: você convida seu time a participar de uma 
discussão e a chegar a um consenso como um grupo. Sua voz 
é igual às outras. 

e Aconselhar: você tenta influenciar o seu time dando-lhes 
conselhos, mas deixa que eles decidam o que fazer com sua 
opinião. 

e Perguntar: você deixa o time decidir. E depois você pergunta 
sobre suas motivações, ou pede que eles o mantenham 
ativamente informado. 

e Delegar: você deixa inteiramente para o time lidar com o 
assunto, e você nem mesmo precisa saber quais decisões eles 


tomam. 


Confesso que no meu dia a dia nao penso sobre que tipo de 
delegação estou fazendo em cada situação, é algo mais intuitivo do 
que pensado, mas é bom conhecer e relembrar essas diferentes 
formas de delegação. Tenho a impressão que entre "dizer" e 
"delegar" há mais do que 5 opções. Navegamos entre essas opções 
de forma fluida de acordo com a senioridade do time, a experiência 
específica do time com o assunto em questão e o quanto o tema em 
questão implica em riscos. 


O conceito de delegação anda de mãos dadas com o conceito de 
microgestão: 
MICROGESTÃO 


Microgestão é o estilo de gestão em que o gerente observa ou 
controla de perto o trabalho de seus subordinados ou 


funcionários. A microgestão geralmente possui uma conotação 
negativa. 


Fonte: https://pt.wikipedia.org/wiki/Microger%C3%AAncia 





A microgestão mostra a incapacidade de delegação do lider. 
Normalmente há duas razões para um líder microgerenciar seu time: 


e Insegurança: o líder é inseguro, preocupado em fazer tudo 
certo, por isso ele quer acompanhar cada detalhe de tudo o que 
está sendo feito. Em alguns (muitos) casos, esse líder fará o 
trabalho de uma pessoa de seu time para garantir que esteja 
sendo feito "do jeito certo". Esse tipo de líder costuma criar 
muitas regras e procedimentos para garantir que as coisas 
estejam sendo feitas do jeito que ele entende como certo. 

e Personalidade: é da personalidade do lider ter prazer em ver 
as pessoas sofrendo sob pressão. Esse líder tende a ser 
abusivo no dia a dia com a equipe. Ele não fará o trabalho de 


ninguém, mas acompanhará de perto todos os detalhes para 
vê-los desconfortáveis sob esse constante escrutínio. 


O mais comum é encontrar líderes com insegurança, normalmente 
pessoas que estão liderando pela primeira vez, mas que 
eventualmente acabam entendendo seu papel e exercendo a 
delegação. Já líderes que microgerenciam devido à sua 
personalidade são mais raros e dificilmente vão mudar. 


Pessoas que estão em um time que está sendo microgerenciado 
tendem a rapidamente se desengajar. Uma vez que estão fazendo 
as coisas do jeito do gestor, não se sentem responsáveis pelo 
resultado obtido, seja o resultado bom ou ruim. Se o resultado for 
bom, o líder provavelmente vai atribuir o sucesso ao seu jeito de 
fazer as coisas. Se der errado, a pessoa que fez o trabalho não se 
sentirá responsável, pois “apenas seguiu ordens”. 


Maneiras de fazer 


Uma das maiores barreiras para a delegação é a certeza que o líder 
tem de que seu jeito de fazer as coisas é o correto. Quando ele era 
um contribuidor individual ele fazia as coisas desse jeito e o 
resultado vinha. Tanto é que ele foi promovido a gestor por fazer as 
coisas daquele jeito. Então, o que ele entende que tem que fazer 
como gestor é garantir que todas as pessoas do seu time façam as 
coisas do jeito que ele faz. Nesse momento a necessidade de 
microgestão desse líder aparece. 


Um líder deve sempre se focar no resultado esperado. A forma 
como esse resultado é atingido é menos importante do que obter o 
resultado. Se uma pessoa de sua equipe faz as coisas de forma 
diferente do que você costuma fazer, isso não significa que a forma 
como ela faz está errada (claro, desde que não seja uma forma 
ilícita e não prejudique as pessoas). É só uma forma diferente de 
fazer as coisas. Talvez até uma forma mais eficiente. O líder precisa 
respeitar essa diversidade de maneiras de se fazer as coisas e 


apenas apresentar a sua forma de fazer quando notar que a pessoa 
nao esta conseguindo evoluir sozinha. 


Oportunidade de aprendizado 


Toda vez que delegamos algo para alguém fazer, caso seja a 
primeira vez que aquela pessoa está fazendo, será uma 
oportunidade de aprendizado. Por esse motivo, é muito provável 
que a pessoa cometa alguns erros e aqui entra um dos trade-offs 
mais difíceis de um lider. Quanto de erro é aceitável? Isso depende 
muito de cada situação, cabe ao líder entender se os erros são 
aceitáveis para permitir o aprendizado, ou se dada a criticidade do 
trabalho a ser feito, erros devem ser minimizados. Devemos sempre 
criar um ambiente propício ao aprendizado a partir dos erros, pois 
esse será o aprendizado mais eficaz. É o que busco fazer com os 
times que lidero. 


13.1 Resumindo 


e Delegar é o ato de confiar uma tarefa e/ou uma 
responsabilidade a alguém. A liderança é um ato contínuo de 
delegação de tarefas e de responsabilidades. 


e Entre não delegar e delegar existem vários níveis de 
delegação que são usados de acordo com o contexto, ou seja, 
do problema a ser resolvido e quem estará trabalhando no 
problema. 


e O conceito de delegação anda de mãos dados com o conceito 
de microgestão, estilo de gestão em que o gerente observa ou 
controla de perto o trabalho de seus subordinados ou 
funcionários. 


e Existem diferentes maneiras de se fazer as coisas para se 
atingir o mesmo resultado. Líderes novos costumam achar que 


só o seu jeito de fazer é o certo. 


e Erros são oportunidades incríveis de aprendizado. Dai a 
importância em tolerar erros no trabalho. 


Pronto, com este capítulo concluímos a parte sobre meus princípios 
pessoais de liderança (pessoas: a prioridade nº 1, sempre; liderar é 
como ser um médico; liderando sob pressão; mentoria é uma via de 
mão dupla; e como e quando delegar). Nos próximos capítulos, 
veremos o que é cultura e quais são os valores que acredito serem 
obrigatórios para criar produtos digitais de sucesso. 


CAPITULO 14 
Cultura e valores 


Após falar dos meus princípios de liderança, vou falar de outro tema 
fundamental para uma head de produto, cultura organizacional e 
valores. São 5 os valores que considero críticos para o sucesso do 
produto: 


e Não desperdice tempo buscando culpados, foque nos 
aprendizados. 

e Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. 

e Lucro e receita são consequência, não devem ser o foco 
principal. 

e Transparência, a fundação de um time de alta performance. 

e Diversidade, a base dos melhores produtos. 


Vamos começar definindo cultura. 


14.1 O que é cultura? 


A palavra cultura vem do latim cultus, que significa "cuidado", e do 
francês colere, que significa "cultivar". Edgar Schein, professor da 
escola de administração de empresas do MIT, foi uma das primeiras 
pessoas a falar sobre cultura organizacional nos anos 1970. 


Segundo ele, cada empresa tinha sua própria personalidade, e sua 
própria forma de agir e reagir às situações; forma esta que é 
passada de funcionário para funcionário desde os fundadores da 
empresa. 


CULTURA ORGANIZACIONAL 


"Cultura é um conjunto de premissas que foram aprendidas e 
compartilhadas por um grupo de pessoas enquanto resolviam 
problemas de adaptação externa e de integração interna. Esse 
conjunto de premissas funciona bem o suficiente para ser 
considerado válido e, consequentemente, ser ensinado aos 
novos membros do grupo como a forma correta de perceber, 
pensar e sentir em relação a esses problemas." 


Fonte: SCHEIN, Edgar. Organizational Culture and Leadership. 
Jossey-Bass, 2010 





A cultura vem dos fundadores da empresa. Os fundadores têm sua 
própria cultura e é natural que a imprimam na organização que 
estão criando. Em função disso, é muito comum se pensar que ela é 
algo que emerge em uma organização. Schein alerta que isso é um 
engano. Culturas podem e devem ser planejadas e é papel do head 
de produto ajudar a planejar e promover a cultura da empresa. 


Por esse motivo, estou compartilhando estes cinco valores que ao 
meu ver são críticos para o desenvolvimento de produtos digitais de 
SUCESSO. 


Não desperdice tempo buscando culpados, foque nos 
aprendizados. 


Quando erros acontecem é comum as pessoas tentarem buscar 
quem foi o responsável pelo erro. Isso pode acabar gerando uma 
cultura do medo de errar e, consequentemente, de querer esconder 
os erros, especialmente se houver alguma punição. 


Os times que não só reconhecem seus erros como os usam como 
fonte de aprendizado e melhoria são os times com melhor 
performance. No livro The High-Velocity Edge: How Market Leaders 
Leverage Operational Excellence to Beat the Competition, Steven J. 


Spear, professor do MIT, explica que um time de alta velocidade tem 
quatro habilidades: 


e Estar preparado para capturar conhecimento e encontrar 
problemas em sua operação. 

e Entender e resolver esses problemas para construir novos 
conhecimentos. 

e Compartilhar o novo conhecimento com toda a organização. 

e Liderar para desenvolver habilidades 1, 2 e 3. 


Segundo o prof. Spear, esse é o segredo por trás do sucesso da 
Toyota por tantos anos. Alcoa é outro bom exemplo. Tinha uma taxa 
de incidentes de trabalho que girava em torno de 2% ao ano. Em 
uma equipe de 40 mil funcionários, isso significa 800 funcionários 
por ano com algum incidente de trabalho, mais de 2 por dia. Para 
combater esse problema, eles implementaram uma política de 
tolerância zero a erros. Antes de implementar essa política, os erros 
eram vistos como parte do trabalho. Agora os funcionários são 
incentivados a relatar erros de operação em 24 horas, propor 
soluções em 48 horas e contar a solução encontrada para seus 
colegas para garantir que o conhecimento se espalhe por toda a 
organização. Isso fez com que o risco de incidentes caísse de 2% 
para 0,07% ao ano! Essa redução na taxa de incidentes significava 
que menos de 30 funcionários por ano tinham algum problema de 
incidente de trabalho depois que a política de zero tolerância a erro 
foi implementada e a Alcoa obteve um aumento de produtividade e 
qualidade semelhante ao da Toyota. 


No livro Smarter Faster Better: The Transformative Power of Real 
Productivity, Charles Duhigg, autor e jornalista premiado com o 
prêmio Pulitzer, compara a performance de dois times de UTI, um 
deles que costuma se reunir diariamente para discutir problemas e 
como evitá-los e o outro que costuma punir funcionários que 
cometem erros. O time que discute e aprende com os erros tem 
performance melhor, o que, para um time de UTI, significa menos 
mortes e mais pacientes recuperados. 


Esse tipo de ambiente que aprende com os erros é conhecido como 
ambiente psicologicamente seguro, ou seja, em que as pessoas 
do time podem fazer seu trabalho sem medo de consequéncias 
negativas. Como head de produto é seu papel criar um ambiente 
assim para seu time e para toda a empresa. 


Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. 


Vejo com alguma frequência o uso de analogias de guerra no dia a 
dia das empresas. Vamos derrotar esse competidor. Vamos criar 
esse war room para tratar desse problema. Isso é uma guerra, 
temos que vencer nossos inimigos. Existe um livro chamado A arte 
da guerra, atribuído um general chinês chamado Sun Tzu que viveu 
entre os anos 550 e 500 a.C., que é considerado um dos 10 livros 
de negócios mais influentes de todos os tempos. Esse livro tem 
frases como "Diante de uma larga frente de batalha, procure o ponto 
mais fraco e, ali, ataque com a sua maior força" e "A suprema arte 
da guerra é derrotar o inimigo sem lutar”. 


Apesar de eu entender a imagem que se quer criar fazendo essa 
comparação de guerra com negócios, para gerar uma motivação 
maior no time de um inimigo comum a ser derrotado, fico 
profundamente incomodado com essa analogia. Guerra é algo muito 
feio e triste. Experimente escrever guerra no Google e clique na 
opção "Imagens". Você verá muitas fotos de dor e de sofrimento. 
Em uma guerra, para alguém ganhar, alguém precisa perder. 


No meu entendimento, negócios é oposto disso. Os negócios mais 
prósperos são aqueles que impactam positivamente todos à sua 
volta, funcionários, clientes, fornecedores, sociedade e até mesmo 
os competidores. Um bom competidor é aquele que o motiva a 
melhorar. Os competidores tiram as empresas da zona de conforto. 
Se não fossem por eles, as empresas evoluiriam de forma bem mais 
lenta. Além disso, competidores podem e devem se juntar em 
associações para irem atrás de objetivos comuns. 


Lucro e receita sao consequência, não deve ser o foco 
principal. 


Sim, o objetivo de toda empresa é crescer e dar lucro, mas esse não 
deve ser o foco. O propósito principal de uma empresa deve ser 
ajudar de alguma forma seus clientes, e a receita e o lucro devem 
ser usados como métricas que indicam se o propósito está sendo 
cumprido. Mas não devem ser as únicas métricas, uma vez que 
sempre há o risco de se obter a má receita, o que pode acontecer 
quando mantemos o foco principal em ter mais receita. 


Imagine uma situação onde você é assinante de um serviço com 
pagamento mensal e, por algum motivo, você precise cancelar sua 
assinatura. Ao tentar fazer isso, descobre que o processo de 
cancelamento é supercomplicado. Isso certamente vai deixá-la 
insatisfeita. A mesma coisa acontece quando você pega uma água 
no frigobar de um quarto de hotel e descobre que a garrafa de água 
custa 3 vezes mais do que em um supermercado. São situações 
que até geram receita para a empresa, mas é uma má receita, que 
deixa os clientes insatisfeitos e que provavelmente fará esses 
clientes não retornarem e até mesmo falar mal de sua empresa 
quando tiverem a oportunidade. 


Por este motivo gosto de fazer uma analogia entre receita e lucro 
com comida: 


Receita é como comida, é necessária, é vital para a saúde e 
para o sucesso de uma empresa, mas não é propósito da vida. 
Você não acorda de manhã e a primeira coisa que pensa é 
"como eu posso conseguir mais comida?". 


Contudo, tanto uma empresa quanto uma pessoa devem estar 
sempre atentas à qualidade da comida que está ingerindo, para 
ter certeza de que ela não vai causar nenhum mal à saúde. 





14.2 Resumindo 


e Cultura é a forma como um grupo de pessoas reage às 
situações do dia a dia. É papel do head de produto ajudar no 
desenho e na promoção da cultura da empresa para garantir 
um ambiente propício para o desenvolvimento de produtos de 
SUCESSO. 


e Tem cinco valores que acredito serem essenciais para ajudar a 
criar uma cultura que propicie o desenvolvimento de produtos 
de sucesso. Neste capítulo falei de 3 desses valores: não 
desperdice tempo buscando culpados, foque nos aprendizados. 
Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. Lucro e receita são consequência, não deve ser 
o foco principal. 


No próximo capítulo vamos conversar sobre a importância da 
transparência na criação de times de alta performance. 


CAPITULO 15 
Transparência, a fundação de um time de alta 
performance 


No capítulo sobre "Dicas de liderança para um gestor de produtos" 
no meu livro Gestão de produtos: Como aumentar as chances de 
sucesso do seu software falo sobre duas dicas de liderança que um 
gestor de produtos, ou qualquer líder, deve usar para ajudar seu 
time a desempenhar melhor: 


e Explicar o contexto: para ter um time mais motivado e 
engajado, é importante as pessoas saberem por que elas estão 
fazendo algo. Estabelecer o contexto ajuda muito no 
engajamento de quem está envolvido com o produto. Eles vão 
entender a sua importância tanto para a empresa — que é dona 
do produto — quanto para os seus usuários. 

e Remover impedimentos: é fundamental para que as pessoas 
do time possam desenvolver o produto. Isso é importante para 
poder termos aquela gostosa sensação de progresso, de que 
estamos fazendo algo, construindo algo. 


Para podermos explicar o contexto, é fundamental sermos 
transparentes, explicar os números da empresa, explicar as 
motivações por trás de cada decisão, incluir o time nas decisões. Eu 
sempre procuro incluir o time nas decisões e, para poder fazer isso, 
é muito importante ser transparente sobre o contexto em que a 
decisão será tomada. 


Um exemplo que gosto de dar é a gestão de estrutura de time, 
sobre a qual vou falar em mais detalhes na parte sobre 
Ferramentas. Para definir e evoluir a estrutura de time, costumo 
fazer isso junto com os líderes do meu time. Nós nos reunimos 
periodicamente - mensalmente ou mais frequente, se necessário - 
para avaliar a estrutura de time, se estão faltando pessoas e se 
temos orçamento para trazê-las. Esse tipo de conversa só pode ser 


feito se eu mostrar claramente qual o orçamento disponível. Ou 
seja, é preciso ter transparência. 


A transparência na gestão das empresas parece algo moderno, mas 
existe há algumas décadas. Vou contar sobre dois casos 
interessantes da década de 1980, um em uma empresa americana 
Springfield ReManufacturing Corp (SRC) e o outro em uma empresa 
brasileira chamada Semco, ambas indústrias. Portanto, a vanguarda 
da gestão participativa. 


15.1 Gestão do livro aberto 


Da mesma forma que existe o conceito de open source, ou código 
aberto, para desenvolvimento e distribuição de software em conjunto 
com seu código-fonte, existe um conceito em administração 
chamado de open-book management ou gestão do livro aberto. 
Esse conceito foi criado por Jack Stack, que escreveu o livro The 
Great Game of Business: The Only Sensible Way to Run a 
Company sobre como aplicou esse conceito na Springfield 
ReManufacturing Corp (SRC), um fabricante de equipamentos em 
Springfield, Missouri. 


O conceito é simples. Os relatórios financeiros da empresa devem 
ficar abertos para todos os funcionários para que sirvam de insumo 
para tomadas de decisão mais conscientes em seu dia a dia. As 
regras básicas são: 


e Dê aos funcionários o treinamento necessário para que eles 
possam entender as informações financeiras; 

e Dê aos funcionários toda informação financeira; 

e Dê aos funcionários a responsabilidade pelos números que 
estão sob seu controle; 

e Dê aos funcionários participação financeira nos resultados da 
empresa. 


Obviamente não dá para praticar open-book management de uma 
hora para outra, mas esse conceito faz bastante sentido para 
qualquer empresa. Em sua forma mais simples, trata-se de uma 
forma de administrar uma empresa que faz com que todos se 
concentrem em ajudar o negócio a ter sucesso. As metas e 
responsabilidades dos funcionários estão diretamente ligadas ao 
sucesso da empresa. Jack Stack ensina a todos os funcionários o 
que é fundamental para o sucesso e como eles podem fazer a 
diferença, tanto individualmente quanto sendo parte de uma equipe. 
Os funcionários sabem e compreendem como cada um contribui 
para o desempenho financeiro da empresa, de forma a entenderem 
verdadeiramente o funcionamento do negócio. 


A SRC foi criada em 1983 quando 13 funcionários da International 
Harvester compraram uma parte daquela empresa que reconstruia 
motores de caminhão, com $100.000 de seu próprio dinheiro e $8,9 
milhões em empréstimos, com o objetivo de salvar 119 empregos. O 
preço das ações em 1983 era de $0,10 e aumentou em 1988 para 
$13 por ação. Em 2015, a ação valia mais de $199. 


15.2 Clóvis Bojikian, ex-diretor de RH da Semco, 
sobre como implementar a democracia 
organizacional 


Em agosto de 2008, tive a oportunidade de conhecer e conversar 
com Clóvis Bojikian, diretor de RH da Semco desde o início dos 
anos 1980. Ele trabalhou com Ricardo Semler na implementação da 
estrutura de gestão participativa que fez da Semco uma das 
empresas brasileiras de maior sucesso no mundo. Vou contar aqui 
resumidamente o que Clóvis contou: 


Definindo o contexto - Semco 


Clóvis começou contando um pouco sobre a Semco, uma empresa 
de sucesso há 25 anos. Seu principal produto eram as bombas 
hidráulicas navais. A principal preocupação era a diversificação do 
portfólio de produtos uma vez que a indústria de construção naval 
estava dificuldades. A diversificação estava sendo feita por meio de: 


e novas licenças: para produzir e comercializar outros produtos 
como misturadores e agitadores; 

e aquisição de empresas brasileiras que eram operadas por 
multinacionais: geladeiras e máquinas de limpeza são 
exemplos; 

e joint ventures: foi assim que a Semco entrou no negócio de 
serviços. Manutenção industrial, conservação de edifícios, 
inventários são alguns exemplos. 


Com essa diversificação, em 20 anos, a empresa cresceu de 300 
para 4.000 funcionários. 


Definir contexto - Clóvis Bojikian 


Clóvis graduou-se em pedagogia. Algum tempo depois, ele estudou 
administração de empresas. Ele trabalhou pela primeira vez como 
diretor do "Colégio de Aplicação da USP", uma escola experimental 
muito famosa nos anos 60 onde novos métodos de ensino foram 
experimentados, uma das escolas mais avançadas de sua época. 
Saiu devido a algumas pressões durante a ditadura militar iniciada 
em 1964. Em seguida, ingressou na Ford, na época com 4.000 
funcionários, como gerente de RH. A Ford estava adquirindo a 
Willys, uma montadora de automóveis com 16.000 funcionários. 
Havia pouca liberdade para o profissional de RH trabalhar ("em uma 
equipe vencedora ninguém quer fazer mudanças”), então ele 
decidiu sair e se juntar a Bombas Hidráulicas KSB, onde pôde 
experimentar algumas ideias que tinha. Mas devido a uma mudança 
de CEO, a liberdade diminuiu. Naquela época, Clóvis foi conversar 
com Ricardo Semler, foram "muitas horas de conversa", como 
Clóvis destacou. Ricardo tinha apenas 22 anos na época e acabava 
de assumir a presidência da Semco. Ele estava procurando um 


profissional de RH que pudesse ajuda-lo a implementar os conceitos 
de gestao participativa que ele estava pensando. Clovis, 48 anos, 
adorou essa conversa e a sinergia com Ricardo e decidiu assumir a 
responsabilidade de dirigir o RH da Semco. 


As raízes da gestão participativa 


A Semco é uma fábrica e, como qualquer outra fábrica, os 
trabalhadores não gostavam de ir trabalhar. Toda semana eles 
contavam as horas até o próximo fim de semana. Esse foi o 
principal desafio de Clóvis: "Como motivamos as pessoas?" 
Algumas constatações de Clóvis: 


e Ninguém motiva ninguém. 

e A motivação vem da pessoa. 

e Precisamos criar condições para que as pessoas se sintam 
motivadas. 

e As pessoas que demonstraram mais interesse pelo trabalho sao 
as que “estão no comando”. 


E sua conclusão, com base nessas constatações, era de que: 


As pessoas mais motivadas são os que mais participam. 


É isso é fácil de entender. As pessoas que "estão no comando" são 
as pessoas que mais participam dos negócios tomando decisões e 
acompanhando os resultados de suas decisões. Mais participação 

significa mais interesse e mais motivação. 


Exercitando a participação 


Para exercer a participação, Clóvis recomenda começar com 
situações simples e não essenciais ao negócio. Ele deu dois 
exemplos da Semco: 


Restaurante dos funcionarios: os funcionarios normalmente 
reclamavam do restaurante para o pessoal de RH. Essa reclamação 
era documentada e analisada pelo RH, mas nem sempre uma ação 
era tomada. Um dia, o RH resolveu retribuir a reclamação com uma 
pergunta: "O que você faria para mudar isso?". Os reclamantes 
ficaram deslumbrados e, por recomendação do pessoal de RH, 
formaram uma comissão para estudar o que poderia ser feito 
melhor. A comissão acabou tendo ideias muito boas e voltou ao 
pessoal de RH, que perguntou: "Vocês conversaram com o pessoal 
do restaurante sobre suas sugestões?". Eles foram ao restaurante, 
discutiram as sugestões e novamente voltaram para o pessoal de 
RH, que apenas disse: "Ok, siga em frente e implemente suas 
sugestões”. Desde então, o restaurante passou a ser administrado 
pelo próprio restaurante, com apoio da comissão de funcionários, 
sem interferência do pessoal de RH. 


Uniforme de funcionários: o estoque de uniformes de funcionários 
estava acabando e uma nova compra se fazia necessária. Em vez 
de apenas fazer um pedido com o fornecedor de mais uniformes, 
eles decidiram fazer uma eleição com os funcionários para que 
decidissem a cor do uniforme. Lembrando, estamos falando da 
década de 1980, eleições não era algo muito comum nessa época. 
Alguns diretores não gostaram da ideia da eleição porque levaria 
tempo e provavelmente seria uma bagunça, mas o fato de que a 
democracia estava sendo exercida em uma situação não 
relacionada ao negócio principal deu início ao experimento. Duas 
cores tiveram muitos votos, e os próprios funcionários propuseram 
fazer uma segunda eleição, apenas com essas duas cores. 
Finalmente, uma foi escolhida. 


Traci Fenton, da WorldBlu, uma organização que fomenta a gestão 
participativa, comentou certa vez que esse é o conceito de 
distribuição de liderança, distribuição de tomada de decisão de uma 
forma que faça sentido. Esse processo de tomada de decisão 
compartilhada pode ser mais lento. Mas a execução é muito mais 
rápida. E a razão disso é que as pessoas participaram da decisão. 


Elas têm propriedade nessa decisão. Elas querem ver o sucesso. E 
é isso que torna a execução muito mais rápida. E é aí que a maioria 
das empresas falha, na execução. 


A próxima etapa - mais perto do core 


Algum tempo depois, os funcionários passaram a definir suas 
próprias metas de produção, normalmente superiores às definidas 
anteriormente pelos executivos. 


Isso mostra como, quando começamos a exercer a tomada de 
decisão participativa com questões não relacionadas ao negócio 
principal, é fácil e natural começar a nos mover para decisões mais 
perto do core do negócio. 


No Brasil, há feriados às terças, quartas e quintas-feiras que as 
pessoas gostam de conectar ao fim de semana para terem um 
feriado mais longo. A famosa "emenda de feriado". Normalmente é 
decisão da empresa definir quem vai emendar o feriado e quem vai 
trabalhar nesse feriado para compensar uma emenda de um feriado 
anterior. Após a experiência do processo de tomada de decisão 
participativa anterior, os próprios funcionários passaram a decidir e 
controlar suas emendas de feriado. 


O próximo passo na Semco foi o desenho das novas funções, 
responsabilidades e plano de remuneração. Foi totalmente escrito 
pelos funcionários com a facilitação e ajuda do pessoal de RH. 
Quando o plano foi finalmente implementado, não apenas todos 
sabiam os salários dos outros, mas todos entenderam por que 
esses salários eram dessa forma e estavam totalmente de acordo 
com isso. 


Outro exemplo interessante de tomada de decisão participativa foi a 
contratação de um novo gerente. Em vez de ser entrevistado 
apenas pelo pessoal de RH e pelo diretor, o gerente também foi 
entrevistado por outros gerentes e pela equipe que lideraria. O 
gerente escolhido teve um ótimo começo, pois era conhecido não 


apenas pelo seu diretor, mas também por todas as pessoas com 
quem trabalharia. A Semco também fez avaliações 360º para que os 
funcionarios analisassem seus lideres. 


Para permitir que os funcionários entendam mais de todo o negócio, 
eles decidiram mudar das linhas de montagem para pequenas 
células responsáveis por toda a peça. Nesse ponto, a Semco 
considerava que tinha uma estrutura de gestão participativa e 
decidiu passar para a próxima etapa. 


A etapa final - uma fatia dos resultados 


E a Semco estava pronta para a etapa final, a participação nos 
lucros. Os donos da Semco decidiram dar vinte e poucos por cento 
do lucro aos funcionários e todo o resto foi decidido de forma 
participativa. Os funcionários criaram um conjunto de princípios. Um 
dos princípios básicos diz mais ou menos assim: "Não basta ser 
transparente, é preciso educar”. A ideia é que não apenas todos os 
números da empresa sejam abertos a todos os funcionários, mas 
todos os funcionários devem ser treinados para serem capazes de 
ler esses números. A demonstração de resultados, o P&L e o fluxo 
de caixa requerem alguns conhecimentos para serem lidos e 
compreendidos. Esta é a base do open book management que 
comentei anteriormente. 


Todos os meses eles fazem uma reunião na Semco para discutir os 
resultados e algumas situações muito interessantes aconteceram 
durante essas reuniões. Um dia, um funcionário questionou por que 
os executivos sempre tinham que se hospedar em hotéis cinco 
estrelas. Não seria possível se hospedar em hotéis quatro estrelas 
de vez em quando? Em outra revisão de relatório mensal, outro 
funcionário notou que a Semco gastou dinheiro pintando a fábrica 
em um mês em que os funcionários tiveram algum tempo livre e eles 
próprios poderiam ter pintado a fábrica. 


Nesse ponto, a Semco implementou horários e locais de trabalho 
flexíveis, permitindo até que o trabalho fosse feito em casa. Lembro 


mais uma vez que isso aconteceu na década de 1980, mais de 30 
anos atras. Uma vez que todos tém interesse no sucesso da 
empresa, é possível implementar essa política. Claro, deve ser 
adotada onde fizer sentido. Por exemplo, não faz sentido para um 
recepcionista trabalhar em casa. Mas se houver dois recepcionistas 
para cobrir um determinado período de tempo, eles podem e devem 
decidir entre si quando cada um deve estar presente. 


Gestão participativa em uma crise 


A certa altura, Clóvis contou sobre uma crise na Semco, nos anos 
do presidente Collor (1990 - 92), em que o mercado foi 
abruptamente aberto para empresas estrangeiras. Isso impactou a 
Semco e os obrigou a fazer um downsize, o que é sempre doloroso. 
Clóvis discutiu com os funcionários como queriam fazer o downsize 
e os funcionários disseram que iriam fornecer uma lista de pessoas 
que não deveriam ser despedidas nem por idade nem por questões 
pessoais e disseram aos gestores que, preservando as pessoas 
dessa lista, os gestores poderiam selecionar quem deveria ser 
dispensado com base em critérios técnicos. Duas coisas que 
podemos ver neste episódio: 


e Mesmo em uma crise, não há necessidade de abandonar as 
inovações de gestão, como gestão participativa. É um bom 
teste para a inovação em gestão, para ver se ela é capaz de 
lidar com a crise em questão. Nesse caso, a gestão 
participativa conseguiu fazer frente à necessidade de dispensas 
por conta de uma crise de mercado. 


e Existem muitos números entre 0 e 1, ou seja, não é uma 
questão de delegação ou não delegação. Existem opções 
intermediárias, existem decisões que os trabalhadores estão 
dispostos a enfrentar e outras que eles não querem enfrentar e 
cada problema exigirá uma combinação diferente. 


Concluindo a conversa 


Ao final da conversa, Clovis comentou que basta coragem para 
implantar a gestao participativa em uma empresa. Erros vao 
acontecer e devemos aprender com eles, mas o resultado final, uma 
empresa cheia de funcionários felizes em ir trabalhar todos os dias, 
vale todos os riscos. 


Pedi a ele que nos contasse sobre um erro ou um momento em que 
pensaram que talvez todo esse processo de tomada de decisão 
participativa não pudesse ser uma boa ideia. 


Ele nos contou uma história muito interessante sobre o sistema de 
relógio de ponto da folha de pagamento. Todos os funcionários 
tinham que fazer check-in na chegada ao trabalho, check-out e 
check-in durante o almoço e check-out novamente no final do 
expediente. Mas era um controle do que é regular, e o que uma 
empresa precisa mesmo saber é o que é irregular (horas extras, 
atrasos, faltas). O RH optou por alterar o sistema de relógio de 
ponto para que o funcionário apenas informasse horas extras, 
atrasos e faltas. E o mais importante, o funcionário deveria informar 
diretamente no sistema. Ela não precisava explicar nada ao chefe. 
No primeiro mês tudo correu bem, mas no segundo mês houve 
fraudes, as pessoas não informavam as irregularidades do horário 
de trabalho corretamente. Eles estavam aproveitando que ninguém 
estava verificando as informações. Muito preocupados, o pessoal de 
RH discutiu o assunto com um grupo de funcionários encarregados 
desse novo sistema. A resposta foi: "Deixe conosco!" Após essa 
conversa, o sistema funcionou muito bem sem nenhuma fraude 
relatada ou percebida. Clóvis comentou que os colaboradores 
perceberam que “quanto mais liberdade temos, mais responsáveis 
temos que ser" e agiram de acordo, para manter sua liberdade. 


15.3 Minha visão sobre a importância da 
transparência na liderança 


Sem transparência não é possível definir o contexto. Em minhas 
experiências, sempre busquei aumentar a transparência das 
informações sobre a empresa (como estão os números, quais são 
os processos) e a participação das pessoas de meus times no 
processo decisório. 


Ao buscar aumentar a transparência das informações sobre a 
empresa, ajudando as pessoas a entenderem os números bem 
como os processos da empresa, quero dar ao time todas as 
informações necessárias para que elas possam conhecer o contexto 
onde estão inseridas e assim entender a motivação e o impacto de 
seu trabalho. É muito difícil alguém fazer um trabalho de qualidade 
sem ter clareza sobre por que aquele trabalho precisa ser feito e 
qual o impacto que ele terá na empresa, em seus funcionários e 
seus clientes. 


Quando busco aumentar participação das pessoas de meus times 
no processo decisório, eu o faço por dois motivos. Primeiro, acredito 
que todas as pessoas têm o direito de tomar decisões sobre seu 
próprio trabalho, e por isso a transparência das informações sobre a 
empresa é tão importante. Sem essas informações é difícil para 
qualquer um tomar boas decisões. A segunda razão é que, quando 
as pessoas estão envolvidas no processo decisório, seu 
comprometimento com o resultado é muito maior. 
Consequentemente, as chances de obter bons resultados 
aumentam consideravelmente quando as pessoas participam do 
processo de tomada de decisão. 


15.4 Resumindo 


e Toda líder, para ajudar seu time a desempenhar melhor, precisa 
explicar o contexto e remover impedimentos. 


e Para podermos explicar o contexto, é fundamental sermos 
transparentes, explicar os números da empresa, explicar as 
motivações por trás de cada decisão, incluir o time nas 
decisões. 


e A transparência na gestão das empresas parece algo moderno, 
mas existe há algumas décadas. Dois exemplos interessantes 
vêm da década de 1980. Um em uma empresa americana 
chamada Springfield ReManufacturing Corp (SRC), que criou o 
conceito de gestão do livro aberto. O outro em uma empresa 
brasileira chamada Semco, do Ricardo Semler, onde Clóvis 
Bojikian, seu diretor de RH, implementou a gestão participativa. 
Ambas são da década de 1980 e são indústrias, ou seja, a 
vanguarda da gestão participativa. 


e Com transparência, é possível dar às pessoas as informações 
necessárias para que elas entendam o contexto e motivação do 
trabalho que estão fazendo e consigam tomar melhores 
decisões sobre esse trabalho. 


No próximo capítulo vamos entender por que diversidade é tão 
importante para o sucesso do time de desenvolvimento de produto. 


CAPITULO 16 
Diversidade, a base dos melhores produtos 


Tenho visto com cada vez mais frequência manifestações sobre 
diversidade. Não sou muito de assistir TV, mas certo dia em 2017 
acabei vendo um pouco de TV Globo. Peguei o final do Jornal 
Nacional e o início da novela. No Jornal Nacional, vi uma matéria 
sobre a PUC de São Paulo inaugurando banheiros unissex - 
lembrando que PUC é Pontifícia Universidade Católica, uma 
universidade ligada à religião Católica. Em seguida, na novela 
apareceu uma personagem que estava contando para os pais e 
familiares que ela nasceu no corpo errado, que era um homem que 
havia nascido em um corpo de mulher, ou seja, que ele era 
transgênero. Em seguida, durante o intervalo, veio a campanha da 
Globo intitulada “Tudo começa pelo respeito” sobre respeito à 
identidade de gênero. 


Isso é muito bom! Aceitar e respeitar as diferenças é a base para 
evoluirmos como sociedade e construirmos um futuro cada vez 
melhor para nós, para nossos filhos e para toda a humanidade. 


Quando faltam o respeito e a capacidade de aceitar a diversidade, 
podem acontecer situações muito ruins, por exemplo, de pais 
rejeitando o próprio filho. Fiquei bastante impressionado quando li o 
relato da Daniela Andrade, consultora sênior da ThoughtWorks, 
onde ela conta que: 


"Como fui expulsa da casa dos meus pais, por ser transexual — 
e aqui eu digo que a primeira grande violência que sofremos é 


dentro de casa — há muitos anos não tenho parentes com quem 
contar em momentos de necessidade, todos deram as costas 
para mim." 





Como é possível um pai rejeitar a própria filha? Sou pai e sei como 
o amor de pai é algo muito intenso, capaz de passar por cima de 
qualquer problema para podermos sempre ajudar e suportar nossos 
filhos. Estava conversando outro dia com minha esposa sobre esse 
relato e sobre a dificuldade das pessoas em aceitarem as 
diferenças, ao ponto de rejeitarem seus próprios filhos. Foi nesse 
momento que minha esposa disse uma frase que me marcou. Ela 
disse que, em última instância, todas as pessoas são diferentes. 
Transgênero, cisgênero, heterossexual, homossexual, bissexual, 
assexual, negro, branco, amarelo, jovem, adulto, meia-idade, 
terceira idade, brasileiro, canadense, francês, vietnamita, 
fluminense, mineiro, paulista, carioca, belo-horizontino, corredor, 
ciclista, nadador, engenheiro, arquiteto, advogado, quem gosta de 
música pop, rock, jazz, clássico e assim por diante. Mesmo gêmeos 
idênticos são diferentes. 


Se todas as pessoas são diferentes, aceitar e respeitar as 
diferenças não é só desejável, é necessário e obrigatório para que 
possamos viver em sociedade de uma forma mais harmônica e 
sustentável. São valores que devem ser ensinados para todas as 
pessoas desde o berço. 


16.1 E o que diversidade tem a ver com gestão de 
produtos digitais? 


Além da importância de aceitar e respeitar as diferenças para ajudar 
a criar uma sociedade mais harmônica e sustentável, a diversidade 
vai ajudar a criar produtos digitais cada vez melhores por dois 
motivos: 


e Diversidade traz novos pontos de vista. Ter um time de 
desenvolvimento de produtos mais diverso traz novos pontos de 
vista e novas maneiras de pensar, o que ajudará a desenvolver 
um produto melhor. Não é à toa que o time de desenvolvimento 


de produtos é composto de engenheiros de software, designers 
de experiência do usuário e gestores de produto. Cada pessoa 
tem visões diferentes do que é um bom produto e essas 
diferenças, quando bem trabalhadas pelo time, é o que ajuda a 
criar um produto melhor. 


e Da mesma forma que o grupo de clientes que usa o seu 
software é diverso, seu time também deveria ser. 
Normalmente os times de desenvolvimento de produto de 
software são compostos em sua maioria por homens, só que a 
população do Brasil é mais diversa. Tanto na Conta Azul como 
na Locaweb, mais de 88% do time é composto de homens. Só 
que esses times fazem produtos que serão usados pela 
população brasileira, que é composta por 48,2% de homens e 
51,8% de mulheres segundo o IBGE (Instituto Brasileiro de 
Geografia e Estatística). Vale lembrar ainda que a divisão 
"homens" e "mulheres" é simplista e que a diversidade de 
gênero é não binária, ou seja, há outras identidades de gênero 
além de feminino e masculino. 


Por isso é tão importante refletir e conversar sobre o assunto 
diversidade. Só assim você poderá pensar em questões tão 
essenciais para o sucesso do seu produto. Como melhorar a 
diversidade do seu time de desenvolvimento de produto? Como 
fomentar discussões que trazem diferentes pontos de vista e ajudam 
a enxergar sob novos ângulos o seu produto e os problemas que ele 
ajuda a resolver? 


Em todos os times que liderei eu trouxe esse tema para ser 
discutido. Juntos pensamos em como poderíamos melhorar essa 
diversidade. Um exemplo interessante do resultado desse trabalho 
ao longo de 12 meses foi o que conseguimos fazer no Gympass, 
com um aumento de 5 pontos percentuais. 


Setembro de 2018 


Mulheres 


Homens 





Figura 16.1: Time de desenvolvimento de produto do Gympass em setembro de 2018 
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Figura 16.2: Time de desenvolvimento de produto do Gympass em agosto de 2019 
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Figura 16.3: Evolução da diversidade do time de desenvolvimento de produto do Gympass 


Na Conta Azul conseguimos algo similar entre 2016 e 2018 com um 
aumento de 6,1 pontos percentuais. 
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Figura 16.4: Time de desenvolvimento de produto da Conta Azul em 2016 
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Figura 16.5: Time de desenvolvimento de produto da Conta Azul em 2018 
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Figura 16.6: Evolução da diversidade do time de desenvolvimento de produto da Conta 
Azul 


16.2 Diversidade de perspectivas 


A equipe de desenvolvimento de produto é composta por 
engenheiras de software, designers de experiência do usuário e 
gestoras de produto. Cada uma tem uma perspectiva diferente do 
que é um bom produto e essas diferenças são o que ajudam a criar 
um produto melhor, quando as diferenças são bem resolvidas pela 
equipe. 


Algum tempo atrás, ouvi a seguinte frase: 


O fato de duas pessoas discordarem não significa 


necessariamente que uma delas esteja errada. 





Isso realmente me fez pensar na diversidade de perspectivas. Isso 
tem a ver com empatia, uma das 7 características essenciais de um 
gestor de produto. Empatia é a habilidade de alguém de pisar no 
lugar de outra pessoa para entender suas aspirações, motivações, 
necessidades e problemas. Qual é o seu contexto? Como ela vê e 
ouve as coisas? O que a faz entender as coisas nessa perspectiva? 


Existe uma ótima ferramenta chamada mapa de empatia, que tem o 
objetivo de ajudar as equipes a obter uma visão mais profunda de 
seus clientes. 


Pensa e sente? 


Ganhos 





Figura 16.7: Mapa de empatia (adaptado da fonte: 
https://docs.google.com/drawings/d/1IXxZwlSoSWySYU5CsPOs8yf4wsUWO0S8Qo5kshCVe 
Y5l/edit? pli=) 


As pessoas tém diferentes origens, diferentes historias, diferentes 
conhecimentos. Devemos reconhecer e respeitar essas diferenças e 
entender que às vezes não chegaremos a um acordo, mas tudo 
bem, desde que respeitemos a perspectiva uns dos outros. Talvez 
possamos criar uma terceira perspectiva a partir das duas 
diferentes. Talvez possamos decidir experimentar uma delas, ou 
ambas, e ver e comparar os resultados. 


Desde que haja respeito e empatia, a diversidade traz muitos bons 
resultados para todos. 


16.3 Resumindo 


Existem duas razões principais que motivam a construção de 
times de desenvolvimento de produtos digitais diversos. A 
primeira é que a diversidade traz novos pontos de vista. A 
segunda razão é que da mesma forma como o grupo de 
clientes que usa seu produto é diversa, sua equipe de 
desenvolvimento de produto também deve ser. 


As pessoas têm diferentes origens, diferentes histórias, 
diferentes conhecimentos. Devemos reconhecer e respeitar 
essas diferenças e entender que às vezes não chegaremos a 
um acordo, mas tudo bem, desde que respeitemos a 
perspectiva uns dos outros. 


Está em nossas mãos tornar o ambiente de desenvolvimento de 
produtos digitais mais inclusivo. O caminho para isso acontecer 
é trazer o tema à tona e torná-lo parte das conversas. 


Com este capítulo, terminamos de ver o que é cultura e quais são, 
na minha opinião, os 5 principais valores que toda a empresa deve 
ter para desenvolver produtos de sucesso: 


Não desperdice tempo buscando culpados, foque nos 
aprendizados. 

Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. 

Lucro e receita são consequência, não deve ser o foco 
principal. 

Transparência, a fundação de um time de alta performance. 
Diversidade, a base dos melhores produtos. 


Nos próximos capítulos vamos ver mais dois valores que, com base 
em minha experiência, são o coração de uma cultura de produto 
digital. 


CAPITULO 17 
Lançamento antecipado e frequente 


Nos capítulos anteriores vimos meus princípios pessoais de 
liderança: 


e Pessoas: a prioridade nº 1, sempre. 
e Liderar é como ser um médico. 

e Liderando sob pressão. 

e Mentoria é uma via de mão dupla. 

e Como e quando delegar. 


Vimos também o que é cultura empresarial, um conjunto de 
maneiras de resolver problemas e reagir à situação compartilhado 
por um grupo de pessoas trabalha junto. E vimos os 5 valores 
necessários para criar produtos digitais de sucesso: 


e Não desperdice tempo buscando culpados, foque nos 
aprendizados. 

e Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. 

e [Lucro e receita são consequências, não devem ser o foco 
principal. 

e Transparência, a fundação de um time de alta performance. 

e Diversidade, a base dos melhores produtos. 


17.1 Cultura de produto 


Acontece que esses valores são necessários, mas não suficientes. 
Existe um conjunto de quatro valores que são de fato o núcleo de 
todo time de desenvolvimento de produtos digitais. São os valores 
que compõem a cultura de produto, que nada mais é do que o 
conjunto de comportamentos dos times de desenvolvimento de 


produtos digitais que produzem os melhores resultados. Os quatro 
valores, que serão tema deste e dos próximos capítulos, são: 


e Lançamento antecipado e frequente 
e Foco no problema 

e Entrega de resultado 

e Mentalidade de ecossistema 


Vamos começar com o primeiro: Lançamento antecipado e 
frequente. 


Quanto mais cedo apresentarmos o produto a seus usuários, 
melhor, pois poderemos receber feedback de usuários reais que 
poderão usar o produto em seu próprio contexto. Existem 3 razões 
que justificam essa necessidade de lançar seu produto ou 
funcionalidade o quanto antes e frequentemente. 


Momento da verdade 


Por mais pesquisas, entrevistas e protótipos que você faça, O 
momento da verdade, ou seja, o momento em que você saberá se o 
seu produto é, de fato, a solução de um problema de um conjunto 
de pessoas, é quando ele estiver nas mãos de seus clientes, no 
contexto onde eles precisam do produto. 


Quanto mais tempo você demorar para colocar seu produto na rua, 
mais tempo demorará para aprender com pessoas reais se você 
está no caminho certo. E pior, mais passos você certamente estará 
dando na direção errada. 


Você só vai saber se o produto que você fez realmente resolve o 
problema de algumas pessoas se elas o usarem. Quanto mais 
tempo demorar para isso acontecer, mais tempo vai levar para saber 
se ele é ou não é a solução do problema. 


E se não for, o que você faz? Conserta, ajusta, muda! Quanto mais 
cedo você souber que o que você está desenvolvendo não está no 


caminho certo, melhor, pois menos tempo, energia e dinheiro você 
desperdiçará indo no caminho errado. 


Excesso de funcionalidades 


Existe um limite de funcionalidades que o usuário consegue 
entender. Quando colocamos funcionalidades demais, em vez de 
criarmos uma solução para o problema do cliente, acabamos 
criando um novo problema para ele. 


Kathy Sierra, reconhecida instrutora de programação e de 
experiência do usuário, criou um gráfico de funcionalidades que 
ilustra de forma clara e divertida como a satisfação do usuário 
diminui à medida que aumentamos a quantidade de funcionalidades 
de um produto. 


Curva de Funcionalidades 
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Figura 17.1: Curva de satisfação do usuário como função da quantidade de funcionalidades 
(fonte: 
https://headrush.typepad.com/creating passionate users/2005/06/featuritis vs t.html) 


Retorno do investimento 


Quanto mais tempo seu produto demorar para ter usuarios e, 
consequentemente, clientes que em algum momento pagarão pelo 
seu produto, mais você terá de investir do seu próprio bolso. Veja a 
seguir um gráfico típico de retorno de investimento de um produto 
(ROI). 


Enquanto você não o lançar e não tiver receita, tudo o que você terá 
é custo. Ou seja, você estará na parte de investimento da curva. 
Isso só muda quando você começar a ter receita e esta for maior do 
que os custos mensais. Então você entra na área descrita a seguir 
como rentabilidade mensal. Só depois de alguns meses nessa área 
é que você terá o retorno do seu investimento. Veja como o caminho 
é longo. 
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Figura 17.2: Retorno do investimento 


Agora veja no gráfico adiante, como um atraso de 3 meses em obter 
receita pode atrasar em 6 meses a obtenção do retorno do 


investimento. Sera que esses 3 meses de atraso em obter receita 
valem a pena? O que vocé vai fazer nesses 3 meses realmente 
compensam 6 meses de atraso no retorno do investimento? 
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Figura 17.3: Retorno do investimento postergado 


Por outro lado, veja só o que você ganha se conseguir acelerar o 
desenvolvimento de seu produto e lançá-lo 3 meses antes do 
planejado. Você ganha 6 meses de retorno do investimento! E a 
explicação para isso não é só porque você adiantou a entrada de 
receita, é porque você gastou menos para poder lançar o produto 
mais rápido. Veja no gráfico a seguir. 
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Figura 17.4: Retorno do investimento antecipado 


17.2 Se vocé nao tem vergonha da sua primeira 
versao, demorou demais para langar 


Reid Hoffman, fundador do LinkedIn disse certa vez que: 


“Se vocé nao tem vergonha da primeira versao do seu produto, 


você demorou demais para lançar”. 





Para ilustrar essa frase, que de certa forma sumariza o valor de 
lançamento antecipado e frequente, resolvi pegar prints da tela da 
primeira versão de alguns serviços bem conhecidos. 


[ Welcome to Thefacebook ] 


Thefacebook is an online directory that connects people through social networks at colleges. 


We have opened up Thefacebook for popular consumption at Harvard University. 


You can use Thefacebook to: 

e Search for people at your school 

e Find out who are in your classes 

e Look up your friends’ friends 

e See a visualization of your social network 


To get started, click below to register. If you have already registered, you can log in. 





Figura 17.5: Facebook 2005 
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Figura 17.6: Facebook 2005 
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Figura 17.9: Twitter 2006 
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Na era da Internet profissional a definição dos fornecedores representa uma 
questão estratégica. É necessário contar com uma empresa que possua a 
estrutura adequada e que permita utilizar todos os melos disponíveis para pôr 
em prática grandes idélas. 


Disponibilidade, segurança, comprometimento e muita experiência é o que a 
Locaweb oferece, com soluções completas e que atendem a cada uma de suas 
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PRÊMIOS | A LocaWeb tem o imenso prazer de 
informar aos seus clientes que todo o esforço, 
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atuando desde o seu início foi, mais uma vez, 
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- INOVAÇÃO TECNOLÓGICA (PCWorld). 














1 GBPS ( 1000 MBITS/S ) | A LocaWeb expande seu 
link para 1 Gbps ( 1000 Mbits/s ). Temos a satisfação 
de comunicar que a LocaWeb ampliou a sua conexão com a Embratel 
de 100 Mbits/s para 1000 Mbits/s - ou 1 Gbps. Esta expansão multiplica 
por dez nossa capacidade de banda e nos coloca como o serviço de 
hospedagem que, de longe, possui o maior link instalado com o núcleo 
do backbone da Embratel. 














Figura 17.10: Locaweb 2002 
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Figura 17.11: Conta Azul 2011 
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Figura 17.12: Ágil ERP (Conta Azul) 2008 
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Figura 17.13: Gympass 2014 


A MAIOR EMPRESA DE CONSULTORIA E VENDA DE IMÓVEIS DO PAIS. 





Figura 17.14: Lopes 1998 


17.3 MMF - Minimal Marketable Feature 


Minimal Marketable Feature ou MMF vem de um livro de 2003 
chamado Software by Numbers, de Mark Denne e Dra. Jane 
Cleland-Huang. Neste livro, eles introduzem o conceito de: 


METODOLOGIA DE FINANCIAMENTO INCREMENTAL 
(INCREMENTAL FUNDING METHODOLOGy - IFM), uma abordagem 
baseada no ROI (Return on Investment - Retorno do 
Investimento) para o desenvolvimento de software em que o 


software é desenvolvido e entregue em blocos cuidadosamente 
priorizados de funcionalidades valorizadas pelo cliente. Esses 
blocos são conhecidos como Funcionalidades Mínimas 
Comercializáveis ou Minimal Marketable Features - MMFs. 





É um conceito anterior ao de MVP, que traz a vantagem dessa 
mentalidade de implementar o mínimo necessário para cada 
funcionalidade do produto. A diferença básica entre MVP e MMF é 
que, enquanto MVP fala de um produto mínimo viável, ou seja, 
precisa de um produto completo, mesmo que mínimo, para poder 
ser apresentado a possíveis usuários, o MMF traz esse conceito do 
mínimo para o nível da funcionalidade. 


Para ilustrar o MMF, eles usaram um exemplo muito simples de 
entender: imagine que você tenha que construir um sistema de 
internet banking na web. Existem muitos recursos e pode levar 
muitos meses ou até anos para esse produto ser entregue com 
todos os recursos "obrigatórios". Ao pensar em termos de MMF, 
devemos olhar para aqueles recursos "obrigatórios" e descobrir se 
podemos lançá-los de forma independente, ou seja, se um 
determinado recurso, se lançado de forma independente, traria 
algum valor para o cliente. Em um sistema de internet banking pela 
Web, poderíamos optar por liberá-lo apenas com extrato da conta e 
nenhum outro recurso. Esse seria um sistema de internet banking 
muito simples, mas, se lançado assim que estiver pronto, e não 


depois que alguns outros recursos também estiverem prontos, ele 
trara valor para o cliente mais cedo. E sempre que vocé entrega 
valor ao cliente, você também entrega valor a sua empresa. Além do 
cliente satisfeito, neste exemplo você provavelmente reduziu o custo 
que sua empresa tem em servir esses clientes, pois se os usuários 
não obtiverem seus extratos de conta pela internet, eles certamente 
usarão outra forma de obter essas informações e provavelmente 
esta outra forma não é tão econômica quanto o acesso via internet, 
como ir a uma agência ou a um caixa eletrônico. 


Uma funcionalidade mínima comercializável (MMF) é mínima, 
porque se fosse menor não seria comercializável. E uma MMF é 
comercializável pois, quando lançada como parte de um produto, as 
pessoas usam (ou compram) a funcionalidade. 


Da próxima vez que você estiver planejando um novo produto ou 
conjunto de funcionalidades para um produto existente, tente pensar 
em termos de MMF. Pode trazer muito valor para você, seus clientes 
e para sua empresa. 


17.4 Resumindo 


e Existe um conjunto de quatro valores que são de fato o nucleo 
de todo time de desenvolvimento de produtos digitais. São os 
valores que compõem a cultura de produto, que nada mais é 
do que o conjunto de comportamentos dos times de 
desenvolvimento de produtos digitais que produzem os 
melhores resultados. 


e As três razões para você lançar logo seu produto são que (i) 
esse é o momento da verdade, (ii) assim você evita o excesso 
de funcionalidades e (iii) acelera o retorno do investimento. 


e Se você não tem vergonha da sua primeira versão, demorou 
demais para lançar. 


e Minimal Marketable Feature ou MMF é um conceito anterior ao 
de MVP, que traz a vantagem de trazer essa mentalidade de 
implementar o mínimo necessário para cada funcionalidade do 
produto. 


No próximo capítulo veremos a importância de nos focarmos em 
entender bem o problema a ser resolvido antes de pensarmos em 
soluções. 


CAPITULO 18 
Foco no problema 


E da natureza humana resolver problemas. Sempre que ouvimos 
falar de problemas, entramos quase imediatamente no modo de 
solução: começamos a buscar soluções para o problema. No 
entanto, se antes conseguirmos um melhor entendimento sobre o 
contexto em que o problema ocorre e a motivação para resolvê-lo, 
há mais chances de conseguirmos encontrar soluções mais simples 
e fáceis de implementar. 


É comum ver outras áreas pedindo à equipe de desenvolvimento de 
produtos que implemente o recurso A ou B porque precisamos dele 
para fechar um negócio ou para não perder esse grande cliente. Um 
exemplo comum que tenho ouvido atualmente é “precisamos 
implementar o Apple Pay e o Google Pay como um novo método de 
pagamento”. A questão aqui é que, falando em soluções, perdemos 
o foco no problema que originou essa solução. 


Qual é o problema? 


Para ajudar as pessoas a se focarem no problema, pergunte sempre 
“Qual é o problema?”. Quando uma nova solicitação de 
funcionalidade chega à equipe de desenvolvimento do produto, 
devemos agradecer ao solicitante pelo pedido e, em seguida, 
devemos perguntar sobre o problema que gerou a solicitação. Cada 
membro da equipe de desenvolvimento de produtos precisa ter esse 
comportamento sempre que uma solicitação de nova funcionalidade 
for recebida. 


Ao colocar isso em prática, em breve as solicitações virão nao 
apenas com uma solução, mas também com muitas informações 
sobre o problema. É interessante ver essa mudança cultural, mas 
requer a disciplina dos membros da equipe de desenvolvimento de 
produtos para sempre perguntar sobre o problema. E quando 


menciono os membros da equipe de desenvolvimento de produtos, 
estou me referindo a todos, nao apenas aos gestores de produto, 
mas também aos designers e as engenheiras e engenheiros de 
produto. 


18.1 Mentalidade de problema vs. solução 


A principal vantagem de nos focarmos em entender melhor o 
problema é que, quanto mais tempo investirmos nisso, mais fácil 
será encontrar uma solução e há boas chances de que essa solução 
seja mais simples e rápida de implementar do que a primeira 
solução que pensamos. 


Aqui está uma ótima citação de Albert Einstein: 


“Se eu tivesse uma hora para resolver um problema, gastaria 55 


minutos pensando sobre o problema e cinco minutos pensando 
nas soluções.” 





Einstein acredita que a qualidade da solução que você gera está em 
proporção direta com sua capacidade de identificar e compreender o 
problema que espera resolver. 


Deixe-me contar uma pequena história para ilustrar isso. Durante a 
corrida espacial, os cientistas se depararam com o problema de 
escrever no espaço onde não houvesse gravidade para fazer a tinta 
cair em uma caneta esferográfica. Os americanos começaram seus 
esforços de P&D e depois de algum tempo e alguns milhões de 
dólares, eles construíram uma caneta com um pequeno motor que 
bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, 
OS russos decidiram usar lápis. 


The Fisher Space Pen 
Sealed Pressurized Ink Cartridge 


Ultra-hard Sliding float separates Gas plug 


tungsten carbide ball ink from pressurized 
(= = CN O 


Stainless steel, preceision- Thixotropic ink in a Ink will not dry out for 
machined socket prevents hermetically sealed and over one hundred years! 
leaks and oozing, yet pressurized reservoir Writes at any angle at 
delivers instant uniform writes three times longer temperatures of -30°F to 
ink flow +250°F 


Developed For 
Made in U.S.A. NASA 





Figura 18.1: Caneta que escreve em ambientes sem gravidade (fonte: 
https://penningtonplanetarium.wordpress.com/2016/12/22/why-astronauts-use-space-pens- 
instead-of-pencils/) 


Essa historia mostra um bom exemplo de como pular direto para a 
solução pode nos fazer gastar tempo e dinheiro desnecessários 
para chegar a soluções incompletas ou exageradas. É uma questão 
cultural, ou seja, um comportamento que podemos e devemos 
mudar. E o primeiro passo para mudar um comportamento é 
reconhecer quando ele acontece. Quando um membro da equipe de 
desenvolvimento de produto recebe uma solicitação para 
implementar algo, ele deve perguntar à pessoa que trouxe a 
solicitação qual é o problema que esse "algo" deve resolver e por 
que é necessário resolvê-lo. 


Aqui estão alguns exemplos das empresas em que trabalhei. 


Na Locaweb, provedora de hospedagem web no Brasil, os serviços 

de hospedagem e e-mail podem parar de funcionar devido a fatores 
externos como o domínio que está associado à hospedagem e ao e- 
mail não ser renovado. 


Primeira solugao: Registro.br, o registrador brasileiro de dominios 
.br lançou uma API para permitir que a Locaweb cobrasse o dominio 
do cliente em nome do Registro.br. A princípio, a ideia parecia boa, 
já que a Locaweb cobrar o domínio parecia a forma mais fácil de 
garantir que o cliente saiba que tem que pagar pelo registro do 
domínio para manter os serviços de hospedagem e e-mail 
funcionando corretamente. Porém, quando analisamos mais a 
fundo, vimos que essa solução poderia gerar alguns problemas. O 
cliente seria cobrado duas vezes pelo mesmo registro de domínio 
porque o Registro.br continuaria cobrando o domínio. O que 
acontece se o cliente pagar as duas contas”? E se ele pagar apenas 
o Registro.br? E se ele pagar apenas Locaweb”? Além disso, 
implementar um novo tipo de cobrança em que cobraríamos por um 
serviço de terceiros era algo novo para a equipe da Locaweb. Novos 
processos teriam que ser cuidadosamente projetados. 


Solução real: começamos a nos perguntar se haveria maneiras 
mais simples de resolver o problema de ajudar nosso cliente a não 
esquecer que ele tem que pagar pelo registro de domínio no 
Registro.br. Como seria possível cobrar pelos serviços do 
Registro.br, foi possível acessar as informações sobre o dominio 
prestes a expirar. Decidimos desenhar uma solução mais simples: 
implementar uma régua de comunicação com este cliente avisando- 
o da importância de pagar ao Registro.br para garantir que os 
serviços de e-mail e hospedagem continuem funcionando 
normalmente. Esta é uma solução muito mais simples do que 
implementar um processo de faturamento dobrado. Se o Registro.br 
nos fornecer a URL de cobrança, podemos enviar as informações 
desse link ao cliente e as chances de solucionar o problema 
aumentarão ainda mais. E uma sequência de comunicação é muito 
mais simples e rápida de implementar do que um processo de 
faturamento duplicado. 


Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas 
empresas), usamos contadores como um de nossos canais de 


distribuição e queríamos aumentar as vendas por meio de 
contadores. 


Primeira solução: compras em lote, onde os contadores 
adquiririam um número fixo de licenças do Conta Azul para revender 
aos seus clientes. Um sistema de gerenciamento de compras em 
lote levaria cerca de 3 meses para ser implementado, pois deveria 
permitir que os contadores comprassem licenças da Conta Azul a 
granel, mas só deveria começar a cobrar do cliente da contadora 
quando esse cliente realmente ativasse a licença. 


Solução real: os contadores não se importavam com as compras 
em lote. O que eles queriam era dar um desconto aos seus clientes 
para que eles pudessem assinar a Conta Azul com esse desconto 
exclusivo proporcionado por seu relacionamento conosco. O custo 
para implementar isso foi zero, pois o sistema já tinha um recurso de 
gerenciamento de descontos. 


No Gympass, um parceiro de fitness que estava ingressando em 
nossa rede solicitou que apresentássemos seu waiver (termo de 

isenção de responsabilidade) a todos os usuários que fizessem o 
check-in em suas instalações. 


Primeira solução: mudar nosso aplicativo para pedir aos usuários 
que vão a este parceiro de fitness que leiam seu waiver em nosso 

aplicativo e marquem um checkbox informando que leram e estão 

de acordo. 


Solução real: nenhuma alteração em nosso aplicativo. Usamos um 
campo de texto personalizável na configuração de uma academia 
em nosso sistema que normalmente é apresentado aos usuários 
que farão check-in nessa academia para apresentar o seguinte 
texto: “Ao fazer o check-in, você concorda com os termos e 
condições localizados em http://fitnesspartner.com/waiver EA 


Não me interprete mal, é muito bom que todos tragam soluções 
sempre que quisermos discutir algo a ser feito pela equipe de 
desenvolvimento de produto. Quanto mais ideias de solução 


tivermos, melhor. No entanto, precisamos nos educar para ter um 
entendimento mais profundo do problema por tras dessa solução, 
para que tenhamos a chance de encontrar soluções mais simples e 
rápidas para implementar. E é, em última análise, o trabalho da 
gestora de produto e de todos os membros da equipe de 
desenvolvimento de produto perguntar qual é o problema e por que 
precisamos resolvê-lo. 


18.2 Projetos vs. problemas 


O ano novo é tempo de retrospectiva e planejamento. O que 
normalmente é feito a cada trimestre pela maioria das equipes de 
desenvolvimento de produtos é feito de forma mais intensa na 
virada do ano, em conjunto com outras áreas da empresa. É o 
processo de planejamento anual, que normalmente vem junto com o 
processo de orçamento. O que faremos neste novo ano que está 
chegando? Quais são os principais projetos que trabalharemos ao 
longo do ano? 


Mesmo que o planejamento seja superimportante para ter clareza 
sobre quais projetos são prioridades para o novo ano, esta lista de 
projetos pode fazer você perder de vista um aspecto muito 
importante do planejamento, o “porquê”. 


Não é incomum ver o planejamento de ano novo para uma equipe 
de desenvolvimento de produto, e até mesmo para toda a empresa, 
como uma lista de projetos. Para ajudá-lo a ver sua lista de projetos 
em um ângulo diferente, adicione 2 colunas: 


e uma para descrever quais são os problemas que você está 
tentando resolver em cada projeto; 

e e outra para descrever para quem você está tentando resolver 
este problema. 


Ja discuti as questões de ter uma mentalidade orientada para a 
solução versus uma mentalidade orientada para o problema, mas 
quando se trata de planejamento de ano novo, esse problema fica 
ainda mais evidente. Os benefícios de ter clareza sobre os 
problemas que deseja resolver e para quem você planeja resolvê- 
los são: 


Garantir que os problemas estejam alinhados com a visão e 
estratégia da empresa: quando focamos em projetos, é fácil perder 
de vista os problemas que estamos tentando resolver, para quem 
planejamos resolver, e se são esses problemas que realmente 
precisamos resolver. 


Definir quais problemas são mais importantes para resolver: 
priorizar projetos sem saber quais problemas esses projetos 
resolvem, e para quem, pode tornar as prioridades não alinhadas 
com o que é realmente importante para a empresa. Porém, para 
sermos mais eficazes em trazer o resultado desejado, devemos 
priorizar os problemas a serem resolvidos e garantir que a 
priorização esteja alinhada com a visão e estratégia da empresa. 


Resolver mais de um problema com o mesmo projeto: às vezes, 
você pode descobrir que está tentando resolver mais de um 
problema com um projeto, e isso pode não ser um problema. Mas 
você precisa saber disso. Talvez você possa ter soluções mais 
simples se tratar cada problema separadamente. Talvez nem todos 
valham a pena resolver neste momento. 


Verificar se os projetos são as melhores soluções: quando 
mudamos o foco dos projetos para os problemas e temos uma 
visibilidade clara da prioridade dos problemas, fica mais fácil 
verificar se os projetos listados são a melhor solução para o 
problema em questão. Às vezes, podemos encontrar soluções que 
são mais fáceis de implementar quando mudamos nosso foco para 
a compreensão dos problemas. 


Entao pegue sua lista de projetos e crie essas duas colunas, 
problemas a serem resolvidos em cada projeto e para quem os 
problemas serão resolvidos. Isso ajudará você a se concentrar nas 
coisas mais importantes para este novo ano. 


18.3 Equipes solucionadora de problemas vs. 
equipes implementadoras de solução 


Marty Cagan, uma referência bem conhecida na comunidade de 
produtos digitais, escreveu há algum tempo um artigo interessante 
sobre equipes de produtos x equipes de funcionalidades, onde 
explica a diferença entre três tipos de equipes, as equipes de 
entrega, as equipes de funcionalidades e as equipes de produto. Ele 
define de cada tipo de equipe da seguinte forma: 


e As equipes de entrega não são multifuncionais (basicamente 
apenas desenvolvedores mais um product owner que 
administra o backlog), não estão focadas no resultado (as 
pessoas são todas orientadas à entrega de funcionalidades) e 
não têm autonomia (estão lá para codificar e entregar). 


e As equipes de funcionalidades geralmente são 
multifuncionais (têm pelo menos uma designer e uma gestora 
de produto), mas ainda se preocupam com a produção e 
entrega de funcionalidades. 


e As equipes de produto são multifuncionais, focadas e 
avaliadas pelo resultado, e têm autonomia para apresentar 
soluções que funcionem. 


Ele explica que os melhores resultados para a organização dona do 
produto e para os usuários desse produto vêm das equipes que ele 
chama de equipes de produto. Ele tem usado muito a palavra 
empoderado (empowered) para descrever esses times. 


Qualquer produto digital existe para dois propósitos principais: 


e Ajudar a empresa dona do produto digital a atingir seus 
objetivos. 

e Resolver os problemas e atender as necessidades de seus 
usuários. 


Portanto, qualquer produto digital e suas funcionalidades são 
soluções para problemas da empresa dona do produto e soluções 
para resolver os problemas do usuário e atender às suas 
necessidades. 


Neste contexto de produto digital, quando digo que gastar mais 
tempo entendendo o problema produz as melhores soluções, quero 
dizer que somos capazes de entregar o mais rápido possível o 
melhor produto e funcionalidades para resolver o problema em 
mãos com software de boa qualidade e boa experiência de usuário. 


Solucionar problemas vs. implementar solução 


O que Marty descreve como equipes de entrega e equipes de 
funcionalidades são equipes de implementadores de soluções. 
Essas equipes trabalham na implementação de uma solução 
concebida por outra pessoa. E essa outra pessoa normalmente é 
alguém da chamada "área de negócios”, que pode ser alguém de 
vendas, marketing, sucesso do cliente, suporte ao cliente, finanças, 
operações, um diretor, um vice-presidente ou um fundador. Em tal 
equipe, o gerente de produto gerencia principalmente o backlog e 
ajuda a equipe a entregar a solução solicitada, o designer de 
produto se concentra principalmente em desenhar uma interface 
agradável e os engenheiros têm que codificar e implantar a solução 
solicitada. As equipes de implementação da solução fazem o que foi 
solicitado, com pouco ou nenhum compromisso com a qualidade da 
solução, ou mesmo se a solução implementada realmente resolve o 
problema. Podem também ser chamadas de "fábrica de 
funcionalidades". Sua performance é medida pela quantidade de 
funcionalidades que o time produz. 


Por outro lado, o que Marty descreve como equipes de produto 
empoderadas são equipes de solução de problemas. Essas equipes 
trabalham para compreender profundamente as causas do 
problema, o contexto e a motivação que as pessoas têm para 
resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor 
solução para o problema em questão. 


Existem três razões principais pelas quais as equipes de solução de 
problemas são mais eficazes do que as equipes de 
implementadores de soluções: 


Conhecimento de produto digital: não há ninguém melhor do que 
os membros da equipe para encontrar a melhor solução de produto 
digital para um problema. Uma solução entregue o mais rápido 
possível, com boa qualidade de software e boa experiência do 
usuário. Isso acontece porque uma equipe de solucionadores de 
problemas é uma equipe multifuncional composta por engenheiros 
que entendem a tecnologia disponível, designers de produto, que 
têm um conhecimento profundo dos usuários, suas dores e 
necessidades, e gestores de produto, que têm um bom 
entendimento do contexto empresarial do problema a ser resolvido. 


Duas cabeças pensam melhor do que uma: este velho ditado 
significa que é mais fácil para duas pessoas que se ajudam 
resolverem um problema do que para uma pessoa resolver um 
problema sozinha. Uma equipe de solucionadores de problemas não 
descarta nenhuma sugestão de solução das "áreas de negócios”. 
Na verdade, essas sugestões de solução são muito úteis para 
ajudar a equipe a entender melhor o problema, mas elas devem ser 
consideradas dessa forma, sugestões. Uma equipe de 
solucionadores de problemas primeiro entende profundamente o 
problema e, em seguida, analisa as opções de solução. 


Compromisso: um efeito colateral adicional de uma equipe de 
solução de problemas é que os membros dessa equipe estão 
profundamente comprometidos com o sucesso da implementação 


da solução, uma vez que estão profundamente envolvidos no 
processo de busca da solução. 


Criação de equipes de solução de problemas 


Agora que expliquei por que as equipes de solução de problemas 
são o melhor tipo de equipe de produto que uma empresa pode ter, 
explicarei como construir equipes de solução de problemas. Existem 
três aspectos que precisam ser considerados: 


Ambiente: é fundamental que toda a organização entenda o poder 
de ter equipes de produtos digitais para solução de problemas. A 
velocidade e a qualidade das soluções entregues por uma equipe de 
produto digital que sempre começa a resolver os problemas a partir 
de um entendimento profundo do problema é muito melhor do que 
as soluções entregues por equipes de implementadores de 
soluções. Consequentemente, os resultados do negócio serão 
melhores e mais rápidos. É função e responsabilidade do head de 
produto ajudar a organização a entender isso. 


Qual é o problema: uma maneira muito eficaz de enfocar toda a 
organização para longe da mentalidade de solução e mais próximo 
da mentalidade de problema é perguntar constantemente "Qual é o 
problema que estamos tentando resolver?" e "Por que é importante 
resolver este problema?". Isso ajudará as pessoas de toda a 
organização a mudar sua perspectiva e, consequentemente, 
perceber a importância de um entendimento profundo do problema 
antes de implementar uma solução. Essa é uma mudança de 
comportamento que toda a equipe de desenvolvimento de produto 
digital pode ajudar sua organização a fazer. Sempre que alguém 
pede à equipe de produto para implementar algo, pergunte "Qual é 
o problema que estamos querendo resolver?". 


Confiança: este é um aspecto crítico para construir equipes bem- 
sucedidas de produtos digitais de solucionadores de problemas. 

Normalmente as pessoas da "área de negócios" acreditam ter um 
melhor entendimento do negócio do que as da equipe de produto. 


Esse comportamento fica ainda mais visivel quando a equipe de 
produto digital é nova na organização. Como uma pessoa nova na 
organização pode entender mais sobre o negocio do que quem esta 
na empresa ha anos? Provavelmente ela nao pode, especialmente 
se ela vier de um mercado diferente. No entanto, quem faz parte da 
equipe de produto digital normalmente tem muita experiéncia na 
construção de produtos digitais, provavelmente mais experiência do 
que qualquer outra pessoa na organização. 


Por isso, é fundamental que a "área de negócios" eduque a equipe 
de produto digital sobre os aspectos de negócios da organização. 
Essa busca por educação é papel e responsabilidade dos gerentes 
de produto, que devem aprender com a "área de negócios" e educar 
designers e engenheiros de produto sobre o negócio. Uma forma 
prática de acelerar esse aprendizado é trazer pessoas da "área de 
negócios" para as sessões de discussão sobre o problema. É assim 
que a equipe de produto ganha a confiança das demais áreas da 
organização. 


Acredito que estão claros os benefícios de ter equipes de produto 
digital de solucionadores de problemas versus implementadores de 
solução. Toda a organização precisa entender a diferença a fim de 
pressionar por mais e mais equipes de resolução de problemas. A 
head de produto tem essa como uma de suas maiores 
responsabilidades, ajudar a construir o ambiente e a confiança 
necessária para o sucesso das equipes de solução de problemas. 


18.4 A armadilha do top-down 


Quando falo sobre as diferenças entre equipes solucionadoras de 
problemas vs equipes implementadoras de solução, normalmente 
ouço comentários como "Queremos ser uma equipe de 
solucionadores de problemas, mas na minha empresa todas as 


soluções sao top-down e a única coisa que podemos fazer é 
implementá-las”. 


Essas situações agravam-se quando surge pressão. A pressão mais 
recente que muitas empresas estão sofrendo é a crise do COVID- 
19. Na ânsia de resolver os problemas o mais rápido possível, os 
líderes da empresa pedem às equipes que implementem esta ou 
aquela solução de maneira rápida, muito rápida. 


A armadilha 


Deixe-me agora abordar o elefante na sala, o ambiente de tomada 
de decisão top-down. Isso tem um impacto enorme em qualquer 
equipe neste tipo de ambiente. Sem fazer parte da decisão sobre a 
solução, as pessoas que implementam a solução acabarão por ficar 
desmotivadas. 


Por que estou chamando de armadilha do top-down? Porque muitos 
dos ambientes de tomada de decisão percebidos como top-down 
são isso que acabei de escrever, uma percepção. 


Vamos usar a principal característica que toda gestora de produto 
deve ter, empatia. A habilidade de alguém se colocar no lugar de 
outra pessoa para entender suas aspirações, motivações, 
necessidades e problemas. Pessoas com quem tive a oportunidade 
de falar sobre as características essenciais de um gestor de produto 
sabem o quão importante considero a empatia como um traço crítico 
para PMs de sucesso. 


Aqui estão 2 dicas para ajudar os membros da equipe de produto a 
ter empatia com os chamados tomadores de decisão top-down e 
escapar da armadilha de cima para baixo: 


e Compreendendo a situação: coloque-se no lugar do 
solicitante da implementação de solução. As pessoas resolvem 
problemas, é a natureza delas, e sempre que se deparam com 
um problema, pulam para o modo de solução e tentam 
encontrar e implementar soluções o mais rápido possível. Sob 


maior pressão, como a crise COVID-19, o desejo de encontrar e 
implementar soluções é exacerbado. Na maioria dos casos, as 
pessoas não querem ser tomadores de decisão top-down, elas 
simplesmente têm uma necessidade de resolver o problema o 
mais rápido possível. 


e Alterando o status quo: faça perguntas sobre a solicitação de 
implementação de solução. Que problema estamos 
resolvendo? Para quem? Por que é importante resolver esse 
problema? Por que agora? Por que precisamos entregar algo 
rápido, mesmo comprometendo a qualidade? Se lhe 
perguntarem o motivo de tantas perguntas, explique que está 
tentando entender melhor o problema para ver se existem 
outras soluções mais baratas e rápidas. 


Essas dicas ajudarão todos na equipe de produto a fazer a mudança 
para um processo de tomada de decisão mais colaborativo. 


Na maioria das vezes, as pessoas entendem os benefícios de um 
processo colaborativo de tomada de decisão. Mesmo sob pressão, 
as soluções colaborativas produzirão melhores resultados. Soluções 
concebidas em um processo colaborativo são normalmente mais 
baratas e rápidas de implementar porque mais pessoas tiveram a 
chance de discutir as opções de solução e a equipe que 
implementará a solução selecionada estará verdadeiramente 
comprometida com seu sucesso. 


Para construir, manter e melhorar as equipes de solução de 
problemas e evitar transformá-las em equipes de implementação de 
soluções, especialmente quando sob maior pressão, é fundamental 
evitar a armadilha do top-down. 


Os heads de produto têm o papel e a responsabilidade de promover 
essas mudanças de comportamento para ajudar a construir um 
processo de tomada de decisão mais colaborativo e, 
consequentemente, mais eficaz. 


18.5 Resumindo 


e Um passo muito importante para criar uma boa solução é a 
compreensão do problema. Quando ouvimos sobre um 
problema, imediatamente começamos a pensar nas soluções. 
No entanto, quanto mais tempo gastamos aprendendo sobre o 
problema, mais fácil será encontrar uma solução e há boas 
chances de que essa solução seja mais simples e rápida de 
implementar do que a primeira solução que pensamos. 


e Se você tiver uma lista de projetos para fazer, crie duas colunas 
a mais nessa lista, uma para problemas a serem resolvidos em 
cada projeto e outra para quem os problemas serão resolvidos. 
Isso ajudará você a se concentrar nos problemas a serem 
resolvidos, e não nos projetos, que são a solução. 


e Equipes de implementação de solução são equipes trabalham 
na implementação de uma solução concebida por outra pessoa. 
Equipes de solução de problemas são equipes trabalham para 
compreender profundamente as causas do problema, o 
contexto e a motivação que as pessoas têm para resolvê-lo. Ao 
fazer isso, eles são capazes de implementar a melhor solução 
para o problema em questão. 


e A armadilha top-down é a percepção do processo de tomada de 
decisão sendo feito pelos líderes da empresa, sem 
oportunidade de participação do resto dos funcionários. Essa 
percepção é exacerbada quando uma empresa enfrenta uma 
pressão crescente, como a crise do COVID-19. 


e As pessoas são orientadas para a solução e, quanto maior a 
pressão, mais rápido as pessoas desejam que as soluções 
sejam implementadas. 


e Para ajudar a lidar com essa situação, use a empatia para 
entender o ponto de vista do solicitante de implementação da 


solução e pergunte a ele por que é necessário implementar a 
solução solicitada. 


e Os heads de produto têm a função e a responsabilidade de 
promover essas mudanças de comportamento para ajudar a 
construir um processo de tomada de decisão mais colaborativo. 


No próximo capítulo vamos entender mais sobre o foco em entrega 
de resultados. 


CAPITULO 19 
Entrega de resultado 


No capítulo anterior vimos a diferença entre um time que soluciona 
problemas e um time que implementa soluções. Enquanto um time 
que resolve problemas precisa ter um profundo entendimento de 
cada problema que vai resolver, das pessoas que são afetadas por 
ele, do contexto onde acontece e da motivação das pessoas para 
terem esse problema resolvido, o time implementador de soluções 
se foca em implementar aquilo que lhe é pedido, não se importando 
se o que está sendo implementado serve para algo. 


A medição de entrega de resultado desses dois tipos de times 
costuma ser bem diferente. Por meio da forma como um time 
reporta seus resultados conseguimos claramente saber que tipo de 
time é. Algo como "conte-me sobre seus resultados que lhe direi 
que tipo de time é!". Enquanto o time implementador de soluções 
costuma medir sua entrega de resultado baseado na quantidade de 
funcionalidades entregues, o time solucionador de problemas mede 
sua entrega de resultado baseado em quão bem os problemas 
foram resolvidos. 


19.1 Fábrica de funcionalidades 


Os times implementadores de soluções são aquelas "fábricas de 
funcionalidades" que já mencionamos no capítulo anterior, ou seja, 
cuja principal métrica é a quantidade e a velocidade de entrega de 
funcionalidades. Como essa é sua principal métrica, esse time 
passa a ser medido pelas suas entregas. O time disse que ia 
entregar tal funcionalidade nesse dia, então é isso que a 
organização espera e será isso que a organização vai cobrar do 
time. 


Essa situação nao é tao incomum quanto se imagina. Na Locaweb, 
antes de implementarmos OKRs, o time de desenvolvimento de 
produto era primariamente cobrado por assertividade do 
planejamento. Se o time disse que ia entregar X no dia Y, era isso 
que era esperado do time, com nenhuma preocupação se X era a 
coisa certa a fazer e se ia de fato trazer resultado para a empresa 
ou para os clientes. Ao implementarmos OKRs, conseguimos fazer 
o time cada vez mais focado em entender e resolver problemas. 


Ao me juntar a Lopes, encontrei algo bastante similar. Um time de 
portal, outro de CRM e outro de app, todos eles com entregas 
predefinidas até 6 meses para frente, porque foi isso o que foi 
acordado com a direção da empresa. Inclusive a Lopes tinha 
contratado duas empresas de consultoria que, ao apresentarem seu 
relatório de resultados, mostravam a quantidade de funcionalidades 
entregues como seu principal resultado, porque foi isso que foi 
demandado delas, entrega de funcionalidades. 


É importante notar que uma situação como essa não acontece 
exclusivamente por responsabilidade do time de desenvolvimento 
de produto. É também responsabilidade das pessoas que estão 
fazendo as demandas. Enquanto o time de desenvolvimento de 
produto deve sempre perguntar qual o problema que está tentando 
resolver com aquela demanda, as pessoas que fazem as demandas 
devem sempre contextualizar essas demandas trazendo o problema 
que motivou a demanda. 


19.2 Foco no resultado 


Após meus primeiros 30 dias na Lopes já comecei a trabalhar com o 
time na definição dos OKRs para o próximo trimestre, o que motivou 
inclusive o RH a também fazer seu planejamento baseado em 
OKRs. Depois, esses OKRs foram apresentados para toda a 
liderança da empresa. Foi a forma que encontrei de provocar a 


mudança de cultura e de mentalidade tanto no time de 
desenvolvimento de produto quanto em toda a empresa. 


A maioria dos OKRs que definimos são focados em resultados de 
negócio. Aumento de vendas, aumento da taxa de atendimento e 
assim por diante. É isso o que importa para o negócio. As 
funcionalidades são um meio, não um fim em si mesmo, mesmo em 
empresas 100% digitais, como a Conta Azul e a Locaweb, os 
produtos digitais são um meio para o fim. A Locaweb inclusive deixa 
isso bem explícito em sua missão de "fazer negócios nascerem e 
prosperarem por meio da tecnologia”, enquanto a Conta Azul quer 
“impulsionar o sucesso dos pequenos empreendedores levando às 
pequenas empresas mais organização, controle e tempo por meio 
da tecnologia." Repare que em ambas a tecnologia, o produto digital 
é um meio para se atingir um fim. 


19.3 Resumindo 


e Outro valor fundamental para qualquer time de desenvolvimento 
de produto é o foco na entrega de resultado. 


e É preciso tomar cuidado na definição de resultado. Entregar 
uma funcionalidade não é um resultado. Toda funcionalidade é 
um meio que serve para um fim, o atingimento de um objetivo 
de negócio. 


e Mesmo empresas 100% digitais, cujo produto digital e a 
tecnologia são o core da empresa, têm por foco objetivos de 
negócio. 


No próximo capítulo vamos ver o valor de mentalidade de 
ecossistema. 


CAPITULO 20 
Mentalidade de ecossistema 


Esse valor eu aprendi no Gympass. Era um dos valores corporativos 
da empresa e, na minha opiniao, toda plataforma tem que ter esse 
valor. Muitas vezes me deparei com CEOs e heads de produto de 
plataforma que afirmavam que faziam tudo pelo cliente, que a 
empresa inteira era voltada ao cliente. Contudo, quando eu 
perguntava mais sobre esse tema, eu acabava descobrindo que o 
cliente ao que eles se referiam era apenas um dos atores da 
plataforma e os outros eram tratados apenas como "mal 
necessário”. 


Na descrição do valor no site do Gympass está escrito: 


MENTALIDADE DE ECOSSISTEMA 


Tomamos decisões que criam valor para o nosso ecossistema 
Gympass e nos ajudam a alcançar nossa missão. 





O exemplo que darei sobre mentalidade de ecossistema foi a 
implementação do produto de aulas ao vivo que o Gympass criou 
durante a crise do COVID-19. 


20.1 Diversificando - e digitalizando - um 
portfólio de produtos 


Durante a pandemia do COVID-19, diversificamos - e digitalizamos - 
nosso portfólio de produtos em tempo recorde. Passamos de um 
produto offline, acesso a academias e estúdios, para 4 produtos, 3 
deles totalmente digitais, em menos de um mês: 


e Acesso a academias e estudios: acesso a mais de 50.000 
academias e estudios em 14 paises; 

e Aulas ao vivo: para quem gosta de treinar em grupo ou quer 
reviver a sensação da aula com os colegas da academia; 

e Personal trainers: para quem prefere uma abordagem mais 
personalizada e gosta de se exercitar no seu tempo; 

e Gympass Wellness: pacote de aplicativos com mais de 60 
aplicativos para quem busca opções para melhorar o bem-estar 
físico e mental (da nutrição à sessão de terapia). 


A seguir explico como fizemos isso. 
Visão do Produto 


Quando entrei para o Gympass, em meados de 2018, uma das 
primeiras coisas que fiz foi construir uma visão de produto. 
Tínhamos um propósito muito forte: vencer a inatividade. No 
entanto, para construir um produto digital, precisamos mais do que 
um propósito. 


Visao da Gympass: um mercado de 3 lados 
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Figura 20.1: Visão de produto do Gympass 


Essa visão orientou a definição da organização de desenvolvimento 
de produtos Gympass. Como comentei no capítulo Estrutura de 
time, montamos equipes em torno de cada um dos participantes do 
marketplace, além de uma equipe central que atuava no fluxo de 
pagamentos recolhendo o pagamento das empresas e de seus 
funcionários, fazendo todos os cálculos e determinando o 
pagamento de cada academia parceira. 


Quando eu estava construindo essa visão de produto e discutindo-a 
com diferentes pessoas na organização, foi fácil ver muitas 
oportunidades de expandir esse mercado. Há uma grande 
quantidade de novas categorias de oferta que poderíamos adicionar 
ao nosso marketplace: 
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Figura 20.2: Oportunidades de expansão do Gympass 


Existem 3 tipos de elementos em um mercado: 


e Oferta: bens ou serviços disponíveis para consumo. 

e Demanda: pessoas ou empresas que podem precisar de bens 
ou serviços oferecidos pelo fornecedor. 

e Mercado: onde a demanda encontra oferta e ocorre uma 
transação. 


Esses três elementos se relacionam da seguinte maneira: 


e Entrega de valor: o mercado agrega valor à demanda e à 
oferta. O valor entregue à oferta são pessoas ou empresas 


interessadas em seus bens ou serviços. O valor entregue a 
demanda é um número variado de fornecedores de bens e 
serviços. 

e Pagamento: para ter acesso aos bens e serviços oferecidos 
pelos fornecedores, a demanda paga o mercado e o mercado 
paga a oferta. Normalmente, o mercado retém uma taxa por 
transação. Essa taxa pode ser fixa ou uma porcentagem do 
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Figura 20.3: Dinâmica de um marketplace 


Dada a dinâmica acima, podemos expandir um mercado da seguinte 
maneira: 


e Diversificação da demanda: você pode oferecer os bens e 
serviços do seu mercado para novos segmentos e regides 
geograficas. 

e Diversificação de suprimentos: você pode oferecer novos 
bens e serviços à sua demanda. 

e Entrega de novo valor: você pode oferecer um novo valor para 
sua oferta e demanda. 

e Gestão financeira de pagamentos: como o pagamento da 
demanda para a oferta passa pelo mercado, você pode oferecer 
serviços financeiros tanto para a demanda quanto para a oferta, 
como pagamento antecipado e crédito, e pode gerenciar o 
spread. 
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Figura 20.4: Possibilidade de expansão de um marketplace 


No entanto, tínhamos muito a fazer em nosso produto principal 
naquela época, então não tínhamos energia suficiente para nos 
concentrar na expansão de nosso marketplace e deixamos os 
planos na gaveta. 


Novo empreendimento 


Em outubro de 2019, chegamos a um ponto em que nossa equipe 
de desenvolvimento de produto estava bem estruturada e 
trabalhando adequadamente para enfrentar nossos desafios em 
nosso produto principal, então decidimos nos concentrar na 
expansão de nosso marketplace. 


Decidimos trabalhar em uma ideia chamada “hub de parcerias do 
usuário final Gympass”. O plano era fazer parceria com aplicativos 
de bem-estar e fornecê-los aos nossos usuários. 


Essa nova ideia tinha duas hipóteses principais que precisávamos 
testar: 


e Disposição para parceria de fornecedores de aplicativos. 
Os provedores de aplicativos, assim como as academias, estão 
acostumados com o modelo de receita mensal recorrente. Eles 
aceitariam ser pagos por dia de uso? 


e Disposição de pagar de nossa base de usuarios. Nossa 
base de usuários está interessada em pagar uma mensalidade 
para ter acesso aos aplicativos? 


Para testar nossa primeira hipótese, construímos um deck com a 
proposta de valor que planejávamos entregar aos parceiros e 
conversamos com alguns parceiros em potencial. Apresentamos a 
oportunidade de parceria a 8 potenciais parceiros, dos quais 6 
mostraram interesse e 4 decidiram juntar-se à nossa prova de 
conceito. NEOU, um app de treino de atividade física, 8fit, um app 
de treino de atividade física e de nutrição, Tecnonutri, um app de 
nutrição e ZenApp um app de meditação. 


Ok, nossa primeira hipótese foi validada e precisávamos validar a 
segunda hipótese, a disposição a pagar. Nosso usuário está 
disposto a pagar para ter acesso a esses aplicativos através do 
Gympass? 


Para testar nossa segunda hipótese, construímos um formulário 
simples, onde descrevemos o produto e perguntamos nome, e-mail 
e empresa. Após o usuário fornecer essas informações, ele seria 
direcionado para uma página de assinatura do Paypal, onde ele 
precisa fornecer os dados do cartão de crédito para assinar o 
serviço. O usuário receberia um e-mail com o link de ativação de 
cada aplicativo. Não havia um produto real, apenas um formulário 
para testar o interesse e um e-mail com os links para os aplicativos. 


Inicialmente, o chamamos de Gympass W, o W significando 
wellness (bem-estar). Adicionamos um beta para que todos 
pudessem entender que não era um produto acabado. Mais tarde, 
renomeamos para Gympass Wellness para deixar sua proposta de 
valor mais clara. 


Nosso plano era testar essa prova de conceito com 5 clientes 
corporativos nos EUA e 5 no Brasil, o que nos forneceria uma base 
de potenciais usuários de 15.000 funcionários. Nossa expectativa 
era ter cerca de 200 assinantes. Lançamos internamente - eat your 
own dog food (coma sua própria ração para cachorro) - em 9 de 
março de 2020 e conquistamos 66 inscritos. Em seguida, veio o 
COVID-19. 


COVID-19 


Quando uma empresa é atingida por uma crise, ela precisa olhar 
para estas duas perspectivas: 


e preservar o dinheiro; 
e identificar e se adaptar às mudanças nos problemas e 
necessidades do cliente. 


Embora gestores de produto e as equipes de desenvolvimento de 
produto tenham um papel importante no primeiro, seu papel 
principal é no segundo. 


No Gympass temos 3 clientes diferentes e todos eles 
profundamente impactados pelo COVID-19: 


e academias em muitas cidades foram fechadas para auxiliar nas 
medidas de distanciamento físico aplicadas em muitas cidades 
para evitar a disseminação do COVID-19 e, consequentemente, 
estão perdendo receitas recorrentes de usuários que não 
frequentam a academia; 

e OS usuários, funcionários de nossos clientes, não podem mais 
ir às academias e têm que ficar em casa, mas também têm que 
se manter ativos de alguma forma, mas sua primeira reação é 
cancelar ou pausar sua inscrição no Gympass, pois não terão 
acesso às academias por um tempo; 

e Clientes corporativos, cujos funcionários estão em casa e não 
vão mais a academias, enquanto os RHs se preocupam em 
como manter esses funcionários engajados e produtivos. 


Gympass Wellness, o primeiro produto digital 


Fomos capazes de adaptar nosso piloto do Gympass Wellness em 
tempo recorde para ser oferecido a toda a nossa base de usuarios, 
de forma que eles possam nao apenas permanecer ativos, mas 
também cuidar de sua alimentação e de suas mentes durante esses 
tempos tão desafiadores. Com o Gympass Wellness, fomos 
capazes de atender aos problemas e necessidades dos usuários e 
de nossos clientes corporativos durante a crise. 


E aqui entra a mentalidade de ecossistema. Devemos sempre 
olhar para todos os participantes em nosso mercado e garantir que 
todos se beneficiem de usá-lo. 


Live Classes, o segundo produto digital 


Com o Gympass Wellness, fomos capazes de atender às 
necessidades de nossos clientes corporativos e de seus 
funcionários. E as academias? Ao serem fechadas, estavam 
perdendo receita. Seus clientes não os visitavam mais, então os 
usuários regulares das academias estavam propensos a cancelar 
sua assinatura, enquanto aqueles que costumavam ir às academias 
usando o Gympass não iam à academia durante a crise, o que 
causaria uma perda de receita para as academias também. Para 
ajudar as academias parceiras, decidimos e implementamos em 
tempo recorde 2 soluções: 


e Fornecemos às academias um aplicativo white-label para que 
elas pudessem oferecer a todos os seus clientes, independente 
de serem ou não funcionários de clientes do Gympass, para 
que as academias pudessem entregar valor aos seus clientes, 
ajudando-os a se manter ativos em casa; 


e Fornecemos uma plataforma para as academias agendarem e 
transmitirem aulas ao vivo para todos os usuários do Gympass, 
para que eles possam manter seus instrutores empregados, 


enquanto fornecem aos usuarios do Gympass conteudo 
exclusivo. Essa plataforma é chamada de Live Classes. 


Personal Trainers, o terceiro produto digital 


As Live Classes forneciam uma plataforma 1:N, o que significa que 
um instrutor poderia fornecer orientação de atividade física para N 
usuários. Logo percebemos que poderíamos criar outro produto 
além do Live Classes, orientação de atividade física 1:1, que poderia 
ser disponibilizada nos planos de nível superior do Gympass. Em 
seguida, criamos nosso terceiro produto digital, Personal Trainers. 


20.2 Resumindo 


e Mentalidade de ecossistema significa tomar decisões que 
criam valor para todos os atores de uma plataforma. 


e No Gympass, durante a crise do COVID-19, depois de 
colocarmos o Gympass Wellness para todos os seus clientes e 
os funcionários desses clientes, uma parte importante do 
ecossistema ainda estava sofrendo, as academias. Foi a 
mentalidade de ecossistema que guiou o Gympass para criar o 
produto de Live Classes, que permitiu que as academias 
continuassem operando mesmo estando de portas fechadas. 


Pronto, com este capítulo concluímos a segunda parte do livro, 
sobre Princípios. Aqui vimos meus princípios pessoais de 
liderança: 


e Pessoas: a prioridade nº 1, sempre. 
e Liderar é como ser um médico. 
Liderando sob pressão. 

Mentoria é uma via de mão dupla. 

e Como e quando delegar. 


Vimos também o que é cultura empresarial, um conjunto de 
maneiras de resolver problemas e reagir a situação compartilhadas 
por um grupo de pessoas trabalha junto. Vimos também os 5 
valores necessários para criar produtos digitais de sucesso: 


e Não desperdice tempo buscando culpados, foque nos 
aprendizados. 

e Não compare situações de trabalho com guerra, ninguém quer 
matar ninguém. 

e Lucro e receita são consequência, não deve ser o foco 
principal. 

e Transparência, a fundação de um time de alta performance. 

e Diversidade, a base dos melhores produtos. 


Por fim, vimos um conjunto de quatro valores que são de fato o 
núcleo de todo time de desenvolvimento de produtos digitais. São os 
valores que compõem a cultura de produto, que nada mais é do 
que o conjunto de comportamentos dos times de desenvolvimento 
de produtos digitais que produzem os melhores resultados: 


e Lançamento antecipado e frequente 
e Foco no problema 

e Entrega de resultado 

e Mentalidade de ecossistema 


Vamos agora ver as ferramentas? \o/ 


Ferramentas 


Aqui vou falar sobre as ferramentas que tenho usado nos meus 
quase 30 anos de carreira em liderança de desenvolvimento de 
produtos e que tenho compartilhado com outros e outras líderes 
para possam utilizar com suas equipes. Elas incluem visão, 
estratégia, objetivos, métricas, relacionamentos, contratação, 
feedback e cerimônias. 


Você vai perceber que as ferramentas que vou comentar aqui não 
são softwares como planilhas, apresentações, documentos, Slack, 
JIRA, Confluence etc. Esses softwares costumam ser bem úteis, 
mas eles são só um veículo de documentação, comunicação e 
metrificação das ferramentas que vamos ver. 


CAPÍTULO 21 
Visão, estratégia, objetivos e estrutura de time 


Todos esses itens são, além de conceitos muito importantes, 
ferramentas essenciais para qualquer head de produto. Em todas as 
oportunidades que iniciei como head de produto, esses foram os 
primeiros temas de que eu tratei, começando sempre com visão de 
produto e, em seguida, partindo para os temas de estratégia, 
objetivos e estrutura de time. Esse também é meu primeiro foco 
quando começo algum trabalho de advisoring. Procuro entender 
quais são a visão, estratégia, objetivos e estrutura de time. Caso 
não haja algum desses elementos, eu ajudo as pessoas da empresa 
a OS criarem. 


Já expliquei o que são e como criar cada um desses itens nos seus 
respectivos capítulos da parte |, por isso farei apenas uma rápida 
revisão dessas ferramentas. 


Visão 


Como expliquei no capitulo Visao de produto, para fazer a visao de 
produto é preciso ter clareza sobre os objetivos da empresa com o 
produto, bem como entender profundamente os problemas e as 
necessidades que os clientes têm e que serão resolvidos pelo 
produto. Os 6 passos para construir uma visão de produto são obter 
objetivos estratégicos da empresa, obter entendimento dos 
problemas e necessidades dos clientes, desenhar primeira versão 
da visão, iterar e refinar, comunicar e revisar. 


Costumo documentar e comunicar a visão de produto em uma 
apresentação. Se necessário, coloco alguma introdução teórica 
explicando os conceitos de plataforma e de marketplace. Em toda 
apresentação que faço, reapresento a visão de produto para deixá- 
la clara para todos. 


Estratégia e objetivos 


A estratégia de produto nada mais é do que o caminho que você vai 
seguir para chegar à sua visão de produto. Para criar sua estratégia 
de produto você precisa ter bastante entendimento sobre seu 
mercado, ou seja, os concorrentes, o mercado potencial e acessível, 
o crescimento desse mercado, se existem disruptores e como ele é 
regulado. Você também precisa entender seus pontos fortes e 
fracos, as oportunidades e ameaças. Uma análise SWOT pode 
ajudar. Com essas informações em mãos, você define o que você e 
seu time vão fazer para atingir a visão de produto, quais os objetivos 
que vocês precisam alcançar e quais métricas lhes dirão que vocês 
estão atingindo esses objetivos. OKRs são uma ótima ferramenta 
para trabalhar seus objetivos e métricas. 


Existem alguns livros e cursos falando sobre como definir e usar 
OKRs. Por isso não vou entrar em muitos detalhes aqui. De forma 
bem sucinta, você define junto com o time alguns objetivos para um 
período - normalmente um trimestre ou um ano - e define em quais 
métricas vocês vão mexer para mostrar que o objetivo está sendo 
atingido. 


Costumo documentar os OKRs em planilhas, que uso para 
acompanhar a evolução toda a semana com líderes do meu time de 
desenvolvimento de produtos, e também apresentar e discutir os 
OKRs com outras lideranças e áreas da empresa. A seguir, um 
exemplo: 


Objetivo Atingir recordes de compras por 


KR 1 


KR 2 


KR 3 


KR4 


més em nosso site 

Aumentar de 15,000 para 20,000 15,000 
visitas por semana 

Melhorar a taxa de conversão de 4.5% 
4,5% para 6% 

Diminuir o bounce rate de 35% 35% 
para 20% 

Melhorar o tempo de 3.5 
carregamento das paginas para 

menos de 2 segundos 


TO Responsavel 


Joao 


Joao 


Joao 


Joao 


Suporte Semana3 Semana2 Semana 1 


Marketing 14,000 15,000 
Dados, 4,3% 4,7% 
Engenharia 
Marketing, 32% 35% 
Engenharia 
Engenharia 3.7 3.5 


Figura 21.1: Exemplo de planilha de OKRs 


Note que toda semana os KRs sao atualizados. Cada lider do time 
atualiza seus KRs com seus times toda segunda-feira e, depois, 
lideres e head de produto passam pelos KRs para ver como esta o 
andamento de cada um e se ha algum impedimento em que pode 
ser colocada energia para remover. Gosto de fazer na segunda-feira 
pois ajuda o time a organizar o trabalho da semana. A cadéncia 
semanal é fundamental para ajudar o time a revisar a performance 
no minimo semanalmente e fazer ajustes se necessario. Se a 
cadéncia for maior (quinzenal ou mensal), perdem-se valiosas 
oportunidades de corrigir problemas e remover impedimentos. 


A coluna TO indica o valor inicial da métrica. A coluna responsável 
tem o nome da pessoa que é responsável por aquele KR e que vai 
liderar os esforços para fazê-lo acontecer. E a coluna suporte lista 
as pessoas ou áreas que vão ajudar o responsável. 


Vale relembrar que, quanto mais próximo dos objetivos e das 
métricas de negócio forem os OKRs, melhor será para o time, pois 


ele 7estara trabalhando para ajudar a empresa em seus objetivos e 
resultados. 


Estrutura de time 


No capitulo Estrutura de Time eu disse que times de 
desenvolvimento de produto sao organizados em times minimos, 
também chamados de squads, compostos de engenheiras, product 
designers e product managers. É importante deixá-los o mais enxuto 
possível para ajudar em sua produtividade. Esses times mínimos 
são agrupados em times de produto chamados de tribos de 
produto. 


Há 4 formas de se organizar os times de produto: por produto ou 
funcionalidade, por tipo de usuário, por jornada ou por objetivo. É 
possível também usar dois tipos diferentes de organização criando 
uma organização híbrida. Existem também as tribos estruturais, 
que criam a estrutura necessária para as tribos de produto 
performarem. Times que compõem as tribos estruturais são 
SRE/DevOps, Dados, Arquitetura/Ferramentas/Fundação, Design 
Ops, Segurança da Informação, Sistemas Internos, Engenharia de 
Vendas e Serviços Profissionais. 


Para ajudar a organizar o time, costumo usar um modelo de planilha 
bem simples como a seguinte: 


Estrutura de time 


Squad X Squad Y Squad Z SRE / TI 


Joao Maria 
Leticia 
Carol Rafa 
Tech Lead Edu Beatriz 
Eng Zé Ana Isabel Clemente 
Andreia Joaquim Igor 
Rodrigo 





Figura 21.2: Exemplo de planilha de estrutura de time 


Essa planilha contém a estrutura do time e as pessoas que fazem 
parte dele. Note que não estamos documentando liderança 
funcional, e sim a lideranga de cada time. No exemplo, temos Joao 
como GPM lider da PM Leticia e da PD Carol, Maria como GPM 
lider do PD Rafa e Sandra como lider dos times estruturais de 
SRE/TI, de Dados e do Pedro, que lidera a engenharia de 2 squads 
da tribo A e do squad da tribo B. 


Um ponto importante é que não basta só criar esses elementos e 
depois não os utilizar. Essas ferramentas são proveitosas quanto 
mais você as utiliza. Planilha de OKRs eu uso no mínimo toda 
semana. Visão e estratégia, sempre que tenho oportunidade, eu falo 
sobre esses temas. Estrutura de time, sempre que vamos falar de 
contratações ou mudanças no time, utilizo a planilha que mostrei 
acima. 


21.1 Resumindo 


e Visão, estratégia, objetivos e estrutura de time são, além de 
conceitos muito importantes, ferramentas essenciais para 
qualquer head de produto. 


e Para visão e estratégia, uma apresentação com alguns slides 
é suficiente. Para OKR e estrutura de time, planilhas dão 
conta do recado. 


e Mais importante do que os softwares que você utiliza para 
documentar Visão, estratégia, objetivos e estrutura de time é 
o que você faz com essas ferramentas. Planilha de OKRs eu 
uso no mínimo toda semana. Visão e estratégia, sempre que 
tenho oportunidade, eu falo sobre esses temas. Estrutura de 
time, sempre que vamos falar de contratações ou mudanças no 
time, utilizo a planilha de estrutura de time. 


No próximo capítulo vamos ver como medir e aumentar a 
produtividade de um time de desenvolvimento de produto. 


CAPITULO 22 
Medindo e gerenciando a produtividade 


Como podemos andar mais rapido? Como podemos entregar mais 
com o mesmo time? Por que temos a impressão de que o time esta 
lento? Quando o time era menor, parecia que ele conseguia 
entregar mais. Esses são questionamentos e afirmações muito 
comuns que ouço sobre times de desenvolvimento de produto. Toda 
empresa que tem um time de desenvolvimento de produtos digitais 
gostaria que esse time fosse mais rápido. Neste capítulo vou 
mostrar as duas ferramentas essenciais para conseguir ter times 
mais rápidos e produtivos. 


22.1 Medição 


Não há como melhorar algo que não se mede. O que é velocidade 
de desenvolvimento de produto”? E importante haver uma definição 
clara dessa métrica e consequente mensuração. 


No meu último ano na Locaweb, estávamos nos focando bastante 
em produtividade, ou seja, em como os times de desenvolvimento 
de produto e de software da Locaweb poderiam produzir mais, sem 
precisarmos colocar mais gente nos times, e sem que a qualidade 
das entregas caísse. 


O gráfico seguinte mostra nossos números. Contabilizamos 
quantidades de entregas por semana e, como dá para ver, em 
algumas semanas mais do que quadruplicamos a quantidade de 
entregas por semana. 


Entregas semanais 


CCC CLT CCL CCC Ones me... 


——emêntregas * * * * Média de entregas 
Set/15 a Fev/16 


Figura 22.1: Quantidade de entregas por semana na Locaweb 


Esse aumento de produtividade aconteceu quando o time cresceu 
apenas 10% em quantidade de pessoas, logo, nao da para creditar 
esse aumento de produtividade ao aumento de pessoas nos times. 


Quando ha um aumento desses, além do natural questionamento 
sobre se o aumento de produtividade se deve ao aumento de 
pessoas nos times, outro questionamento que existe é se houve 
queda da qualidade das entregas. Uma das medições de qualidade 
que fazemos é a quantidade rollbacks. Como é possível perceber a 
seguir, mesmo com o aumento de produtividade, a quantidade de 
rollbacks foi reduzida em 40%! 


Rollbacks por semana 


22 rollbacks 13 rollbacks 


Figura 22.2: Quantidade de rollbacks por semana na Locaweb 


Na Locaweb fizemos uns calculos estimados de entregas por 
semana no periodo de setembro de 2015 a fevereiro de 2016. O 
calculo foi bem simples, total de deploys feitos no periodo dividido 
pelo numero de semanas. Passamos, entao, a comunicar toda a 
empresa sobre as entregas da semana. 


Depois que cheguei a Conta Azul, decidimos implementar o mesmo 
tipo de controle de entregas semanais e acabamos conseguindo 
também um bom aumento da produtividade. 


Entregas x Semana 





01/11/16 01/12/16 01/01/17 01/02/17 01/03/17 01/04/17 


Figura 22.3: Quantidade de entregas por semana na Conta Azul 


Tanto na Locaweb quanto na Conta Azul, cada gestor de produtos 
me mandava na sexta-feira as entregas da semana, eu compilava 
os dados e anotava a quantidade de cada semana, gerando esses 
gráficos. A partir do momento em que começamos a medir, ficou 
mais claro o nível em que estávamos, e as ações que passamos a 
fazer visando o aumento de produtividade começaram a mostrar 
resultado no gráfico. Além disso, os times passaram a usar uma 
única ferramenta de medição, o Jira, o que deu a eles uma visão 
melhor de progresso de cada time e permitiu comparações com 
troca de experiência, isto é, algo como “olha que interessante o seu 
gráfico, como vocês conseguiram aumentar esse indicador?”. 


No Gympass, como escalamos a equipe muito rapidamente, 
decidimos controlar o número de entregas por pessoa por semana. 
Contamos as pessoas que ingressaram 2 meses antes, uma vez 
que as pessoas precisam de 1 a 2 meses para se tornarem 
produtivas. Em um trimestre, conseguimos aumentar em 16% nossa 


produtividade por pessoa. O numero de entregas era extraido 
diretamente do JIRA. 


Q3 avg = 0.65 


Entregas por semana por pessoa (16/% aumento) 


Q2 avg = 0.56 
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Figura 22.4: Quantidade de entregas por semana no Gympass 


Na Gympass, também medimos o número de deploys, tanto em 
nosso core, conhecido como monólito, quanto em microsserviços. 
Também conseguimos um aumento considerável em um ano. 


Deploys por més 


O time cresceu 
2,9 vezes no 
mesmo período 











Figura 22.5: Quantidade de entregas por semana no Gympass 


Na Lopes, assim que um deploy era feito, um email era enviado com 
uma lista dos itens "deploiados". Uma das primeiras coisas que fiz 
foi compilar esses relatórios em uma planilha para construir o gráfico 
adiante. Dai foi fácil notar que os deploys não aconteciam todos os 
dias. Aconteciam em média uma vez por semana. Assim que 
notamos isso, definimos OKRs para aumentar a frequência de 
deploys, o que vem surtindo efeito. Os OKRs que definimos foram: 


e Objetivo: Aumentar a cadência de deploys em produção; 

e KR: Aumentar o número de deploys por semana para no 
mínimo 3 (quanto mais melhor); 

e KR: Reduzir o numero maximo de novas features por deploy 
para no maximo 10. 


Itens "deploiados" e deploys por dia 


== BugsPRD == Deploys [E Total Bugs Squad (63) $ Novos (62) 
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Figura 22.6: Quantidade de entregas por semana no Gympass 


22.2 O que impacta a produtividade 


A produtividade de um time de desenvolvimento de produto é 
impactada por vários fatores. Certa vez encontrei um artigo bem 
interessante escrito por Michael Dubakov, fundador da empresa 
Targetprocess onde ele mostra um mapa mental com todos os 
elementos que podem impactar positiva ou negativamente a 
produtividade de um time de desenvolvimento de produto. Esse 
artigo não está mais disponível mas, graças ao site Wayback 
Machine (http://web.archive.org), é possível acessá-lo em: 


http://web.archive.org/web/20150827162352/http://www.targetproces 
s.com/articles/speed-in-software-development/ 


O mapa mental é este aqui: 
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Figura 22.7: Mapa mental da Targetprocess sobre o que impacta a produtividade (fonte: 
http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed- 
in-software-development/) 


Good Features 
Ranking Model 


Este diagrama mostra coisas e atividades que afetam a velocidade 
de desenvolvimento de alguma forma. Verde significa que uma 
atividade aumenta a velocidade. Quanto mais vocé tiver, melhor. 
Amarelo indica que existe algum maximo. Por exemplo, vocé pode 
acumular divida tecnica e aumentar a velocidade, mas, se acumular 
muito, isso o atrasara significativamente. O vermelho mostra coisas 
que retardam o desenvolvimento, quanto menos vocé tiver, melhor. 
A seta verde indica efeito crescente. Por exemplo, o trabalho focado 
aumenta a velocidade de desenvolvimento. A seta vermelha indica 
efeito decrescente. Por exemplo, melhores habilidades de 
desenvolvimento diminuem a complexidade do sistema (bons 
engenheiros criam sistemas menos complexos). 


O que gosto dessa imagem é que ela mostra quão complexo é esse 
tema e quantas coisas podem impactar positiva ou negativamente a 


velocidade do time. Na Conta Azul acompanhavamos esse tema 
todo trimestre na Product Council, reuniao em que conversavamos 
sobre o planejamento trimestral do time de desenvolvimento de 
produto com a liderança. Tinha um slide onde elencavamos todos os 
temas que podiam impactar a velocidade para discutirmos o que 
estávamos fazendo sobre cada um desses tópicos. 


O que já fizemos para aumentar a O que estamos fazendo para aumentar a | O que temos mapeado, mas ainda 
produtividade produtividade não estamos fazendo 
Diminuição do tamanho das histórias - | Componentização da interface - | Treinamento comportamental 
Maior assertividade dos discoveries - | Onboarding de novos funcionários - Ambiente físico 
Organização dos times - | Monolito => microserviços - Autenticação + cadastro único 
Conhecimento profundo dos - | Velocidade de recrutamento - Refactoring do financeiro 
contadores - | Fortalecimento de cultura -  Microservice do Fiscal 
Estoque (débito técnico) - Treinamento técnico e de domínio 
Perfil de acesso (débito técnico) -  Selecdo de gente que entra jogando 
Criação de um time de foundation - | Padrões de interação 
Aquisições - Canary release 
Estabilidade do time (menos saídas) - Terceirização 
Motor contábil e Fiscal - Nova API lugu 
Nova conciliação (débito técnico) - One click microservice 


Figura 22.8: Temas que impactam a velocidade do time de desenvolvimento de produto da 
Conta Azul 


22.3 Coloque o tema produtividade no centro da 
discussão 


Não há bala de prata, com cada time que trabalho foram várias 
ações que tomamos e sempre tivemos a certeza de que sempre há 
mais ações que poderão ser tomadas para aumentar a 
produtividade ainda mais. 


A única bala de prata que existe é transformamos produtividade 
em tema importante de nossas conversas. Todos passaram a 
conversar sobre produtividade e sobre o que poderíamos fazer para 
melhorá-la. 


Esse movimento nos fez iniciar varias mudanças e experimentos 
que nos ajudaram a aumentar consideravelmente nossa 
produtividade. Se você também quer aumentar a produtividade de 
seu time de desenvolvimento de produtos, coloque isso como tema 
central de suas conversas e experimente bastante. Você verá como 
há espaço para melhorar bastante a produtividade dos seus times 
de desenvolvimento de software. 


Outro ponto importante: não deixe para discutir o tema produtividade 
esporadicamente. Minha recomendação é que você o faça 
semanalmente. Criar uma cadência semanal dará oportunidade de, 
a cada semana, experimentar com algo novo e discutir os resultados 
com o time. 


22.4 Resumindo 


e Não existe bala de prata para aumentar a produtividade de um 
time de desenvolvimento de produto. Contudo, existem sim 
duas ferramentas essenciais para ajudar nesse objetivo. 


e A primeira ferramenta é medição. Não ha como melhorar algo 
que não se mede. O que é velocidade de desenvolvimento de 
produto? É importante haver uma definição clara dessa métrica 
e consequente mensuração. 


e A segunda ferramenta é trazer o tema produtividade para o 
centro da discussão. Todos do time de desenvolvimento de 
produto são responsáveis pela produtividade do time. Por isso, 
ao trazer o tema para o centro da discussão, todos poderão 
colaborar para melhorar a produtividade. 


No próximo capitulo veremos como outra métrica que tem impacto 
direto na produtividade, a qualidade. 


CAPITULO 23 
Medindo e gerenciando a qualidade 


Em 2015, decidimos extinguir a função de Quality Assurance (QA) 
de nossa equipe de desenvolvimento de produtos da Locaweb. 
Tinhamos 12 QAs, alguns com perfil de desenvolvedor e outros com 
perfil SysAdmin. Ao propor a extinção da função de QA, alguns dos 
QAs se tornaram devs, enquanto outros assumiram a função de 
administradores de sistemas. Os motivos que nos levaram a 
extinguir a função de QA da Locaweb são: 


e Quando existe uma função de QA separada da função de 
desenvolvimento de software, é comum ouvir frases como “a 
funcionalidade está pronta, agora está em fase de QA”, o que 
denota uma cultura de desenvolvimento de produto em cascata. 
Essa cultura pode aumentar consideravelmente o tempo de 
desenvolvimento e afetar negativamente a qualidade do 
software. 


e Quando há uma função de QA separada da função de 
desenvolvimento de software, também é comum ouvir frases 
como "por que o QA não detectou esse bug?", o que denota 
uma cultura de encontrar os culpados. Essa cultura pode ser 
muito prejudicial ao engajamento e motivação da equipe e, 
consequentemente, impactar negativamente a qualidade do 
software. 


e A qualidade não deve ser preocupação de uma pessoa ou 
equipe, deve ser preocupação de todos os que estão 
trabalhando na criação do software. 


e A qualidade é um requisito não funcional, ou seja, que 
especifica um critério para avaliar o funcionamento de um 
produto digital, enquanto requisito funcional especifica um 
comportamento do software. Desempenho, escalabilidade, 


operabilidade, monitorabilidade sao alguns exemplos de 
requisitos de software nao funcionais que sao tao importantes 
quanto a qualidade. Mesmo assim, nao ha funções definidas 
para garantia de desempenho, garantia de escalabilidade, 
garantia de operabilidade e garantia de monitorabilidade. Por 
que a qualidade é o único requisito nao funcional que tem uma 
função específica dedicada para garanti-la? 


O controle de qualidade se concentra em garantir a qualidade 
do processo de desenvolvimento de software. Se uma função 
separada é necessária para garantir essa qualidade, por que 
não há necessidade de uma função separada para garantir a 
qualidade do processo de gestão de produto, o processo de 
design, o processo de marketing de produto, o processo de 
vendas, o processo financeiro de uma empresa? 


Havia uma preocupação de que, se o próprio engenheiro agora 
tivesse que testar, as entregas demorariam mais para ficar 
prontas. Essa preocupação existia porque os engenheiros 
consideravam que seu trabalho estava concluído - e a entrega 
estava pronta - quando passavam a história para o QA testar. 
No entanto, o conceito de pronto do engenheiro está incorreto, 
pois ele acabou de passar a história para a próxima fase, o 
teste. Do ponto de vista do usuário, a história só está pronta 
quando o usuário pode usar o novo recurso. Portanto, o tempo 
que a entrega permanece no controle de qualidade ainda é o 
tempo de desenvolvimento, mesmo não estando mais nas 
mãos do engenheiro. E esse tempo fica ainda maior quando a 
história passa pelo controle de qualidade, mas é rejeitada e 
precisa voltar para a engenharia. 


Quando entrei na Conta Azul, eles também haviam acabado de 
extinguir a função de QA, e os ex-QAs passaram a ser analistas de 
negócios, principalmente ajudando gerentes de produto. 


Eu vi outras empresas também discutindo a necessidade de QAs e, 
em alguns casos, um debate acalorado emerge em torno deste 


tópico. No entanto, ter ou não ter QAs não deve ser o centro da 
discussão. Ter ou não ter essa função é a solução de um problema, 
normalmente referido como “como podemos melhorar a qualidade 
do nosso produto?”, e esse problema deve ser o centro da 
discussão. 


23.1 Como podemos melhorar a qualidade do 
nosso produto? 


Uma simples pesquisa no Google sobre qualidade de software 
produzirá toneladas de definições normalmente relacionadas ao 
atendimento de requisitos funcionais e não funcionais. Quando o 
software não atende a um requisito funcional ou não funcional, ele 
apresenta um defeito, um bug. Portanto, para melhorar a qualidade 
de um produto de software, precisamos trabalhar em duas coisas: 


e reduzindo seus bugs existentes; 
e não gerando novos bugs. 


Uma boa maneira de controlar isso é ter uma medição semanal de 
seu inventário de bugs e novos bugs por semana e discutir isso 
todas as semanas com a equipe. Fizemos isso no Gympass. 
Definimos no início de cada trimestre qual é a meta para o inventário 
de bugs e a média de novos bugs por semana. 
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Figura 23.1: Quantidade total de bugs no Gympass 


A imagem mostra a evolução do nosso estoque de bugs para o 2º 
trimestre de 2019. Iniciamos o trimestre com 215 bugs em nosso 
estoque e almejamos uma meta de menos de 166 ao final do 
trimestre, uma redução de quase 23%. Fechamos o trimestre com 
um estoque de 136 bugs, uma redução de 36%. Fizemos isso nos 
concentrando não apenas na resolução de bugs em nosso 
inventário, mas também no controle do número de novos bugs por 
semana. 
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Figura 23.2: Quantidade de novos bugs detectados por semana no Gympass 


No primeiro trimestre de 2019, tivemos uma média de 26,2 bugs 
criados por semana. Durante o segundo trimestre, reduzimos essa 
média para 17,4 novos bugs por semana, para um total de 226 
novos bugs durante o trimestre. Isso é uma redução de 33% no 
número de novos bugs por semana. 


Isso parece uma melhoria muito boa, certo? Mas há muito espaço 
para melhorias aí. Deixe-me explicar a matemática do 
gerenciamento de bugs: 


Se fomos capazes de reduzir nosso estoque de bugs de 215 para 
136, isso significa que resolvemos pelo menos 79 bugs. No entanto, 
criamos 226 novos bugs (17,4 novos bugs por semana x 13 
semanas) durante o trimestre. Resolvemos 79 + 226 = 305 bugs 
durante o trimestre, é muito trabalho de correção de bugs. Se 
tivéssemos gerado 90 novos bugs durante o trimestre, uma média 
de 6,9 novos bugs por semana, em vez dos 226 novos bugs, 
poderíamos ter zerado o inventário de bugs. 


Um aspecto adicional da resolução do bug a ser medido é o SLA 
(Service Level Agreement) de resolução, ou seja, quantos dias a 
equipe levou para resolver um bug a partir do dia em que o bug foi 
identificado pela primeira vez. Para isso, classificamos os bugs pela 
sua gravidade, que é o impacto que causa aos usuários e ao 
negócio. Os bugs de maior gravidade são aqueles que precisamos 
resolver no mesmo dia; erros de alta gravidade, em 7 dias e média 
de gravidade, em 14 dias. O gráfico a seguir mostra como 
estávamos no Gympass no quarto trimestre de 2019. 
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Figura 23.3: SLA de resolução de bugs no Gympass 


Essa não é a visualização ideal porque mostra apenas uma imagem 
do momento, e não uma evolução. Para entender a evolução de 
qualquer métrica, você precisa ver como ela se saiu em diferentes 


pontos no tempo. 
Assim que me juntei à Lopes, comecei a trazer esse tema para a 


discussão com os times. Uma das coisas que notamos é que 50% 
dos itens "deploiados" era correção de bugs. Fui informado de que 


"esses bugs eram pegos antes de ir para produção, o que é algo 
bom". De fato, ainda bem que esses bugs não chegaram ao 
ambiente de produção e apareceram para nossos usuários. 
Contudo, eles chegaram à pré-produção e precisavam ser 
corrigidos. Não seria melhor se esses erros nem sequer existissem, 
nem mesmo em pré-produção? 


Os OKRs que definimos para nos ajudar com o tema qualidade 
foram 3 KRs adicionais no objetivo de Aumentar a cadência de 
deploys em produção que comentei no capítulo anterior: 


e KR: Reduzir o número de novos bugs para 5% em pré- 
produção. 

e KR: Reduzir o número de bugs totais para 10% em pré- 
produção. 

e KR: Manter o número de bugs totais abaixo de 5% em 
produção. 


E adicionamos o seguinte OKR: 


e Objetivo: Melhorar a qualidade das entregas das squads. 

e KR: Revisar 100% das novas histórias para encontrar requisitos 
mal definidos e/ou ambíguos. 

e KR: Efetuar revisão de 25% dos Pull Requests dos squads. 

e KR: Mensurar volume de Pull Requests dos squads. 


23.2 Outro exemplo de controle de bugs 


Na Conta Azul dobramos o time de desenvolvimento de produtos 
em um período de 8 meses entre novembro de 2017 e julho de 
2018. Esse crescimento tinha por objetivo aumentar a capacidade 
produtiva do time. 
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Figura 23.4: Quantidade de entregas e de pessoas por semana da Conta Azul 


Além disso dividimos a quantidade de entregas pelo total de 
pessoas no time para avaliar se estávamos conseguindo aumentar 
nossa produtividade individualmente. 
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Figura 23.5: Quantidade de entregas por pessoa na Conta Azul 


Contudo, com o aumento de pessoas no time, acabou aumentando 
a quantidade de bugs. Tanto que o time que já vinha tendo 40% de 
suas entregas como correção de bugs acabou tendo que aumentar 
essa proporção para 60%. Ou seja, apesar de ter aumentado a 
produtividade individual e total, esse aumento de produtividade não 
estava sendo sentido pelo usuário, pois acabava sendo usado para 
refação. 
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Figura 23.6: Percentual de corregao bug na Conta Azul 


Para controlarmos esse problema, aumentamos nosso foco em 
corrigir esses bugs dentro dos SLAs, que eram: 


e 85% dos chamados resolvidos em até 7 dias 
e 98% dos chamados resolvidos em até 30 dias 
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Figura 23.7: SLA de resolução de bugs em 7 dias da Conta Azul 
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Figura 23.8: SLA de resolução de bugs em 30 dias da Conta Azul 


Veja que a qualidade piorou e o cliente sofreu com isso. Mas, depois 
de algum tempo, conseguimos retornar aos níveis de SLA definidos. 
Olhávamos essa métrica semanalmente e, sempre quando 
discutíamos sobre essa métrica, concordávamos que a melhor 
maneira de cumprir o SLA era não criar bugs! 


23.3 Qualidade não é só controle de bugs 


Além do controle de bugs, há vários outros aspectos que impactam 
na qualidade do produto digital que entregamos para os usuários. 
Desempenho, escalabilidade, operabilidade, monitorabilidade são 
alguns exemplos de requisitos não funcionais. 


Quando me juntei ao Gympass, na minha segunda segunda-feira o 
sistema ficou fora para os usuários por volta das 19:00. Comecei a 
perguntar para as pessoas do time o que estava acontecendo e a 
resposta foi que as segundas-feiras são dias de pico de visita às 
academias e que às vazes o sistema não dava conta do volume. 
Como não havia monitoração, não éramos alertados de que o 
volume estava maior que o usual e não conseguíamos nos preparar 
adequadamente. Dois meses depois, quando o Rodrigo Rodrigues 
se juntou ao Gympass como CTO, ele apelidou o evento de "Back 
Mondays". Para endereçar o problema passamos a monitorar e 
implementar uma infraestrutura que desse conta dos picos das 
segundas-feiras. E definimos OKRs para uptime, requests de HTTP 
bem-sucedidos e tempo de reposta do backend. 
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Figura 23.9: Uptime - Gympass 
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Figura 23.10: Requests de HTTP bem sucedidos - Gympass 
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Figura 23.11: Tempos de resposta do backend - Gympass 


23.4 Por que a qualidade é tão importante? 


Qualquer usuário prefere utilizar um produto de boa qualidade que 
se comporte conforme o esperado. Isso é condição sine qua non 
para fornecer uma boa experiência do usuário. 


Além da experiência do usuário, há outro aspecto importante a 
considerar quando falamos sobre qualidade e bugs. Sempre que 
alguém precisa trabalhar na resolução de um bug que foi 
encontrado em um produto digital, essa pessoa precisa parar de 
trabalhar no que quer que esteja trabalhando no momento para 
poder resolver o bug. Esta é uma interrupção no fluxo de trabalho. 
Se essa pessoa fosse capaz de entregar o software sem aquele 
bug, ela poderia continuar a trabalhar em coisas novas sem 
interrupções, o que a tornaria mais produtiva. 


A relação entre produtividade e qualidade 


Tive a oportunidade de participar de um curso do MIT sobre como 
criar organizações de alta velocidade. O curso foi ministrado pelo 

Professor Steven J. Spear, autor do livro The High-Velocity Edge: 

How Market Leaders Leverage Operational Excellence to Beat the 
Competition. Esse é um daqueles cursos muito densos, cheios de 
conteúdo, mas que pode ser resumido em um parágrafo: 


Organizações de alta velocidade são capazes de aprender muito 
rápido, especialmente com suas falhas, e de absorver esse 


aprendizado como parte integrante do conhecimento da 
organização. 





Uma organização de alta velocidade trabalha seguindo os 4 passos 
adiante: 


e Estar preparado para capturar conhecimento e encontrar 
problemas em sua operação. 

e Entender e resolver esses problemas para construir novos 
conhecimentos. 

e Compartilhar o novo conhecimento com toda a organização. 

e Liderar para desenvolver habilidades 1, 2 e 3. 


O exemplo clássico é a Toyota, com a manufatura enxuta e o 
conceito de parar a produção sempre que houver falhas, corrigindo- 
as e usando-as como oportunidade de aprendizado para que não 
aconteçam mais. Essa capacidade de aprender com as falhas é o 
que dá à Toyota a capacidade de permanecer à frente de seus 
concorrentes por tanto tempo. 


Outro bom exemplo é a Alcoa, que tinha uma taxa de incidentes de 
trabalho de 2% ao ano, considerada normal. A Alcoa tem mais de 
40.000 funcionários, portanto, 2% dos incidentes de trabalho por 
ano significa que 800 funcionários por ano têm algum tipo de 


incidente de trabalho. Esse é um numero bastante impressionante e 
preocupante. 


Para combater esse problema, eles implementaram uma política de 
tolerância zero a erros. Antes de implementar esta política, os erros 
eram vistos como parte do trabalho. Agora, os funcionários são 
incentivados a relatar erros de operação em 24 horas, propor 
soluções em 48 horas e contar a solução encontrada para seus 
colegas para garantir que o conhecimento se espalhe por toda a 
organização. 


Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao 
ano! Essa redução na taxa de incidentes significava que menos de 
30 funcionários por ano tinham algum problema de incidente de 
trabalho depois que a política de tolerância a erro zero foi 
implementada e a Alcoa obteve um aumento de produtividade e 
qualidade semelhante ao da Toyota. 


23.5 Falhar rápido vs. aprender rápido 


Um fator importante nos exemplos da Toyota e da Alcoa é que 
reconhecer e aprender com as falhas deve fazer parte da cultura da 
empresa. Isso é algo um pouco mais comum na cultura das 
empresas de tecnologia, mas não tão comum em empresas 
tradicionais. Durante o curso do MIT dividi mesa com um executivo 
brasileiro, do Grupo Globo, um executivo espanhol, da AMC 
Networks International (Walking Dead, Breaking Bad e Mad Men), 
um gerente de projetos alemão residente no Azerbaijão que trabalha 
para a Swire Pacific Offshore (indústria de petróleo e gás) e uma 
estudante de pós-doutorado do MIT em energia solar vinda da 
Arábia Saudita. 


Todos os meus companheiros de mesa eram de industrias mais 
tradicionais. Eu era o único de uma empresa de internet. Os 
executivos da Globo e da AMC estavam lá porque viram a Netflix 
com seu streaming de vídeo sob demanda e o YouTube com seu 
enorme catálogo de vídeos gerados por usuários como grandes 
ameaças, roubando seu público muito rapidamente e eles queriam 
entender como poderiam se defender. 


Embora o tema seja um tanto Óbvio para as empresas de internet, 
especialmente com a cultura de startups de tecnologia que 
valorizam o fail fast (falhar rápido). É isso que torna a Netflix e o 
YouTube uma ameaça às empresas de mídia tradicionais, como o 
Grupo Globo e AMC Networks. No entanto, mesmo isso sendo parte 
da cultura das empresas de internet, sentar e discutir isso com 
pessoas de empresas mais tradicionais foi uma grande 
oportunidade de reflexão sobre a relação entre a falha, o 
reconhecimento da falha, o aprendizado e a alta velocidade: 


e Reconhecer as falhas e usar as falhas como uma oportunidade 
de aprendizagem deve estar bem enraizado na cultura da 
organização. Se as pessoas não tomarem cuidado, à medida 
que uma empresa cresce, ela pode perder a capacidade de 
aceitar as falhas como oportunidades de aprendizado. É muito 
comum que as empresas, à medida que cresçam, sejam cada 
vez mais avessas a falhas e criem uma cultura que, em última 
análise, incentive as pessoas a esconderem erros e falhas. 


e Outro aspecto importante do aprendizado com as falhas é 
tornar esse processo um padrão da empresa. Não adianta 
falhar, reconhecer o erro, afirmar que você não vai mais 
cometer aquela falha e, algum tempo depois, cometê-la 
novamente. Esse processo de aprendizado com as falhas deve 
fazer parte da cultura da empresa. Sempre que uma falha é 
identificada, o aprendizado deve acontecer o mais rápido 
possível para evitar que ela aconteça novamente. Se a mesma 
falha acontecer novamente, algo está quebrado no processo de 
aprendizagem com a falha. 


e Mesmo em empresas de internet, percebo que aprender com as 
falhas é mais comum na equipe de desenvolvimento de 
produtos, uma vez que retrospectivas e aprendizado contínuo 
fazem parte da cultura de desenvolvimento ágil de software. Em 
outras áreas da empresa, aprender com as falhas é menos 
comum. Essa capacidade de sistematizar o aprendizado com o 
fracasso deve permear toda a empresa. 


Mesmo que ouçamos muito sobre a cultura das empresas de 
internet de falhar rápido, falar sobre falhar rápido diverge nosso foco 
do que é realmente importante, aprender rápido. Devemos colocar 
nossa energia no aprendizado, não no fracasso. É o processo de 
aprendizagem que faz evoluir pessoas e empresas. E é a 
capacidade de uma organização aprender rápido, principalmente 
com seus fracassos, que vai permitir que ela se mova em 
velocidades realmente altas. 


23.6 Resumindo 


e Questionar se o desenvolvimento de produto deve ou não ter 
uma equipe de QA dedicada não é a pergunta certa. 


e O problema que você está tentando resolver é como melhorar a 
qualidade do seu produto. 


e Uma boa métrica proxy de qualidade são os bugs. Inventário de 
bugs, novos bugs por semana e SLA de resolução de bugs. 


e Uma equipe de desenvolvimento de produto deve ter todos os 
seus membros seguindo essas métricas e agindo para melhorá- 
las. 


e Gerir bugs não é suficiente para gerir a qualidade do produto 
digital. Desempenho, escalabilidade, operabilidade, 
monitorabilidade são alguns exemplos de requisitos não 


funcionais que impactam diretamente na qualidade do produto 
digital. 


e A qualidade está em primeiro plano para fornecer uma boa 
experiência do usuário. Além disso, é fundamental para 
aumentar a velocidade de sua equipe de desenvolvimento de 
produto. Quanto menos bugs uma equipe tiver para corrigir, 
mais tempo ela terá para se concentrar em coisas novas. 


e Organizações de alta velocidade são capazes de aprender 
muito rápido, especialmente com suas falhas, e de absorver 
esse aprendizado como parte integrante do conhecimento da 
organização. 


No próximo capítulo vamos ver um pouco mais sobre métricas. 


CAPITULO 24 
Métricas 


A essa altura você já deve ter percebido o quanto eu gosto de 
métricas. No meu primeiro livro, Guia da startup: como startups e 
empresas estabelecidas podem criar produtos de software 
rentáveis, eu dediquei 6 capítulos inteiros além de falar sobre 
métricas nos outros capítulos. No meu segundo livro, Gestão de 
produtos: como aumentar as chances de sucesso do seu software, 
são mais 5 capítulos dedicados ao tema de métrica, além de 
novamente esse tema aparecer em outras partes do livro. Aqui não 
é diferente, os dois últimos capítulos falaram bastante sobre 
métricas e tenho falado também em alguns outros capítulos sobre 
OKRs, objetivos, dados e resultados. 


Métricas são ferramentas fundamentais para qualquer head de um 
time de desenvolvimento de produto. Sem métricas é impossível 
saber se o time está progredindo, evoluindo e cumprindo com sua 
missão. Contudo, é muito fácil se perder em quantidades enormes 
de métricas. 


Neste capítulo quero compartilhar um pouco sobre como costumo 
trabalhar com métricas. 


24.1 Tipos de métrica 


Classifico métricas em 3 grandes grupos: 


Internas 


Sao as métricas que mostram como o time de desenvolvimento de 
produto esta nesse momento e tem evoluido. Os dois capitulos 
anteriores mostraram as métricas de produtividade e de qualidade. 
São métricas que ajudam a head de produto e o time a entenderem 
como está o processo de trabalho e onde devem focar a energia 
para melhorar nessas métricas. Como podemos aumentar a 
produtividade? Como diminuimos a quantidade de bugs? Como 
garantimos a melhor performance do produto para nossos usuários? 


Ainda dentro do tema métricas internas, existem outras mais "soft" 
mas também muito importantes para você entender a saúde do seu 
time de desenvolvimento de produto. São métricas que ajudam a 
entender se as pessoas estão felizes trabalhando nesse time, se 
estão alinhadas com a cultura e com o propósito do time e da 
empresa. 


Uma métrica bastante simples de acompanhar é entrada, saída e 
tempo médio das pessoas do time a cada mês. Se saem mais 
pessoas do que entram, pode haver algum problema no time. Se as 
pessoas ficam poucos meses e depois vão embora, é mais um 
ponto de atenção. Você também pode rodar uma pesquisa de NPS 
(Net Promoter Score ou Índice Líquido de Promotores) com as 
pessoas do time periodicamente para entender se eles 
recomendariam trabalhar no seu time para outras pessoas e o 
porquê da resposta. 


A seguir, há dois exemplos do Gympass. No primeiro está a 
evolução da quantidade total de pessoas do time mês a mês, com 
total de novos e total de pessoas que saíram, mostrando também 
quantas dessas saíram voluntariamente, ou seja, pediram para sair. 
No segundo está o eNPS (employee NPS ou NPS dos funcionários), 
que mostra se as pessoas estavam dispostas a indicar o time de 
desenvolvimento de produto do Gympass para os amigos virem 
trabalhar. 


Evolução do time de desenvolvimento de produto 


= Turnover == New Hires 


Contratação 
acelerando 
após 
confirmação de 
funding 

133 novos! 


1519 
16 pessoas 
14 voluntário 


2518 





9 pessoas 
3 voluntário 
2519 
1518 24 pessoas 
13 pessoas 14 voluntário 


11 voluntário 





Figura 24.1: Evolução do time de desenvolvimento de produto do Gympass 


eNPS: 69 


72% promotores 


3% detratores 





Figura 24.2: NPS do time de desenvolvimento de produto do Gympass 


De usuário 


São as métricas que mostram que seu produto está sendo utilizado 
pelos usuários, ou seja, que ele está cumprindo seu objetivo. São as 


métricas de engajamento e de satisfação de seu usuario com o 
produto. Qual seria o engajamento ideal de seu usuário com o 
produto? 


Na Conta Azul queriamos que o produto fosse a primeira janela que 
ele abrisse em seu browser de manhã e a última que ele fechasse à 
noite. Acompanhávamos quantidade de notas fiscais emitidas por 
usuário por semana e, por mês, qual o valor delas. No Gympass, 
acompanhávamos quantos usuários iam à academia por mês, qual 
a frequência de visita às academias e assim por diante. Na Lopes 
estamos acompanhando o uso pelos corretores do novo CRM que 
tem versão web e mobile. Queremos que eles usem pelo menos 4 
vezes por semana e é esse número que acompanhamos. 


Outra métrica de usuário que pode ser útil são as métricas de 
satisfação. Essa métrica tende a ser um pouco mais subjetiva, além 
de ser trabalhosa para medir. Você deve mandar todos os dias uma 
minipesquisa para uma parte de seus clientes. Por isso, antes de 
medi-la e acompanhá-la, recomendo acompanhar de perto o 
engajamento com o produto. Se o usuário está engajado, utilizando 
o produto na frequência esperada, há boas chances de ele estar 
minimamente satisfeito. 


De negócio 


São as métricas que mostram o time de desenvolvimento de produto 
está de fato entregando valor para o dono do negócio. Qual era o 
objetivo que a dona de negócio tinha para o produto? Aumento de 
vendas, diminuição de custos? Esses objetivos variam com o tipo de 
empresa onde está o produto digital. É uma empresa digital, uma 
empresa tradicional ou uma empresa tradicional nascida digital? 


Na Conta Azul, como o produto vendido era o produto digital, as 
métricas de usuário e as métricas de negócio se misturam bastante. 
A quantidade de usuários que utilizam várias vezes por semana são 
aqueles que certamente vão continuar pagando a assinatura mensal 
e, consequentemente, continuarão gerando receita. 


Ja no Gympass, uma empresa tradicional nascida digital, e na 
Lopes, uma empresa tradicional, a receita existe sem a necessidade 
do produto digital. Então, o que o produto digital pode fazer para 
aumentar a receita ou para diminuir os custos? No Gympass, ao 
mesmo tempo que queríamos diminuir os custos de operação, 
automatizando a maioria das tarefas manuais, também utilizavamos 
o produto como potencializador de receita, ajudando o RH dos 
clientes e seus funcionários a entenderem e, consequentemente, se 
tornarem assinantes do serviço. Na Lopes, o foco principal é em 
aumentar as vendas, mas temos também um foco em como diminuir 
os custos de operação. 


Um ponto importantíssimo acompanhar todos os meses é a 
comparação entre o valor entregue pelo produto digital - aumento de 
receita e diminuição de custo - e o custo de desenvolvimento de 
produto. O que se espera é que o valor entregue seja maior do que 
o custo de desenvolvimento. E gerenciar isso é papel do head de 
produto. 


24.2 Acompanhando as métricas 


Métricas podem ser diárias, semanais, mensais, trimestrais e 
anuais. Claro que, quanto maior o período de atualização, mais 
difícil é de entender o comportamento da métrica e tomar decisões 
sobre como impactá-la. Tenho preferência por métricas que 
podemos acompanhar diária e semanalmente. Com métricas 
semanais, em um trimestre temos 13 oportunidades de avaliar uma 
métrica, entender como podemos mexer nela e remover algum 
impedimento que esteja nos atrapalhando no atingimento de algum 
objetivo atrelado a ela. E as métricas diárias dão o pulso do negócio. 
Quanto novos usuários por dia? Quanto usuários cancelaram? 


Na Locaweb sempre acompanhávamos esses números diariamente 
e, se algo estava fora do esperado, positiva ou negativamente, já 


buscavamos entender o que havia acontecido que havia impactado 
o número. Quando fazíamos algo com a intenção de mexer nesses 
números, tal como uma nova campanha de marketing ou de 
retenção, podíamos acompanhar esses resultados diariamente. É 
possível ainda medir com frequência ainda maior em caso de 
produtos com grande escala como, por exemplo, o Search do 
Google. 


Por outro lado, há métricas que têm frequência maior mesmo, como 
o exemplo acima que dei de novas pessoas que entram ou saem 
em um time de desenvolvimento de produto. Mesmo com métricas 
mensais ou mesmo de periodicidade maior, recomendo fazer 
acompanhamento da parcial dessa métrica pelo menos 
semanalmente. Se você só acompanhar mensalmente, em um 
trimestre terá apenas 2 oportunidades de avaliar o andamento e 
corrigir o curso. 


24.3 Resumindo 


e As métricas de um time de desenvolvimento de produto podem 
ser classificadas em 3 grandes categorias: internas, de usuário 
e de negócio. 


e Métricas internas mostram como o time está de saúde: as 
métricas de usuário mostram a relação de seu usuário com o 
produto e as métricas de negócio são aquelas que mostram se 
o produto está, de fato, entregando valor para o negócio. 


e Métricas devem ser acompanhadas com a maior frequência 
possível, no mínimo semanalmente. Mesmo se for uma métrica 
mensal, procure acompanhar as parciais semanais, ou mesmo 
diárias, dessa métrica, para dar maior oportunidade de agir 
mais cedo quando houver uma variação de curso. 


No proximo capitulo vamos ver como gerenciar os relacionamentos 
com as diferentes areas. 


CAPITULO 25 
Relacionamentos 


Como comentei no capitulo Papéis, responsabilidades e 
senioridade, o gerenciamento de expectativas é algo que ocupa 
entre 50 a 80% do tempo de uma head de produto. Seu dia a dia 
gira em torno de seus relacionamentos e interações com muitas 
pessoas dentro e fora de sua organização que têm interesse no 
produto que você lidera. No jargão corporativo, essas pessoas são 
chamadas de stakeholders: 


Nas últimas décadas do século 20, a palavra stakeholder tem 
sido cada vez mais usada para significar uma pessoa ou 
organização que tem um interesse legítimo em um projeto ou 
entidade. Ao discutir o processo de tomada de decisão para 
instituições - incluindo grandes empresas, agências 


governamentais e organizações sem fins lucrativos - o conceito 
foi ampliado para incluir todos com interesse (ou "stake", palavra 
em inglês que significa participação) no que a entidade faz. 


Fonte: https://en.wikipedia.org/wiki/Stakeholder (corporate) 
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Figura 25.1: Evolução do uso da palavra "stakeholder" na literatura (Fonte: 
https://books.google.com/ngrams/graph? 
content=stakeholder&year_start=1960&year_end=2019&corpus=26&smoothing=7&case_in 
sensitive=true) 


Uma gestora de produtos com alguma experiéncia sabe da 
importancia de manter bons relacionamentos com os stakeholders 
do produto. Vou compartilhar aqui duas ferramentas que ajudam a 
mapear melhor esses stakeholders e como deve ser seu 
relacionamento com cada um deles. 


25.1 RASCI 


RASCI é uma ferramenta muito util para ajudar a definir e entender 
os papéis e responsabilidades de cada pessoa e cada função. É a 
abreviação das primeiras letras dos possíveis papéis que uma 
pessoa, área ou função pode ter em uma tarefa: 


e Responsible (encarregado): é a pessoa responsável pela 
execução da tarefa, ou seja, quem tem de liderar o esforço de 
planejar, fazer e concluir a tarefa. Não pode existir mais de um 
responsável por tarefa. É aquela máxima de que cachorro com 
dois donos morre de fome. 


e Accountable (responsável): é a pessoa que responde pela 
tarefa e que tem o poder de delegar para o responsible a tarefa 
a ser feita. Responsible e accountable podem ser a mesma 
pessoa. Também vale a regra de que não pode existir mais de 
um accountable por tarefa. Se responsible e accountable são 
duas pessoas diferentes, o accountable pode ser visto como o 
patrocinador. 


e Support (suporte): são as pessoas ou equipes que trabalham 
junto e sob a coordenação do responsible para a execução da 
tarefa. 


e Consulted (consultado): são as pessoas ou equipes que não 
participam da execução da tarefa, mas que precisam ser 
consultadas antes ou enquanto a tarefa estiver sendo 
executada, pois elas podem dar inputs relevantes para sua 
execução. 


e Informed (informado): são as pessoas ou equipes que não 
participam da execução da tarefa, nem precisam ser 
consultadas antes ou enquanto a tarefa estiver sendo 
executada, mas que precisam ser informadas quando a tarefa 
for concluída. 


A seguir, está um exemplo de uma matriz de responsabilidade 
RASCI entre engenharia, UX, marketing de produtos e gestão de 
produtos que usamos na Locaweb: 


RASCI Produtos Locaweb 


Redes Sociais 

Blog 

Precificação 

Roadmap 

Testemunhos 

Posicionamento (como apresentar o produto para o mercado) 
Estudo de mercado (Segmentação) 
Product Discovery (Persona) 

Product Design / Experience 

Product Identity (identidade visual) 
Product Architecture 

Product Development / Improvement 
Preparar treinamento de equipe comercial 
Preparar treinamento para atendimento 





Figura 25.2: Matriz de responsabilidade RASCI da Locaweb 
Como usar 


O primeiro passo é fazer a matriz de responsabilidades. Minha 
recomendação é preencher essa tabela juntando todas as pessoas 
envolvidas em uma sala, assim pode-se discutir se a divisão de 
responsabilidade está boa para todos e se tem alguma tarefa 
faltando. Muito provavelmente, vão surgir algumas "bolas divididas”, 
mas esse é um ótimo momento para discuti-las e definir quem é o 
responsável. 


Em seguida, deve-se experimentar fazer as tarefas seguindo a 
matriz responsabilidade por algum tempo, tipo um ou dois meses. 
Depois, é importante fazer uma retrospectiva para ver se está tudo 
certo, ou se é necessário algum ajuste. 


Daí para a frente, o uso passa a ser automático e as pessoas não 
precisarão mais se referir à matriz de responsabilidades. A cada 1 
ano ou quando surgir alguma dúvida, ou mesmo quando surgir 
alguma tarefa nova, é bom revisitá-la. 


25.2 Matriz de poder-interesse 


A matriz de poder-interesse (do inglés Power-Interest Grid) é um 
conceito desenvolvido pela primeira vez na década de 90 por 
Aubrey L. Mendelow, e posteriormente explicado no livro, Making 
Strategy: Mapping Out Strategic Success, de Fran Ackermann e 
Colin Eden. Com base no poder e no interesse que uma pessoa ou 
equipe tem em seu produto, você pode classificá-los em 4 
categorias principais. 


Pessoas Atores principais 
Envolver Colaborar 





Interesse 


Definidores de 
contexto 


Consultar 


Multidão 


informar 





Poder 


Figura 25.3: Matriz de poder-interesse 


e Os atores principais são os que têm grande poder e interesse 
no seu produto. Você precisa colaborar frequentemente com 


eles. Os usuarios e clientes do seu produto sao atores 
principais, você precisa colaborar com eles para construir o 
melhor produto que resolva seus problemas e atenda às suas 
necessidades. Em algumas empresas, provavelmente o 
fundador mais próximo do produto também é um ator principal. 
Você deve convidar essas pessoas para qualquer reunião e 
dinâmica em que decisões estratégicas sejam tomadas. 
Agende individualmente para apresentar as decisões e pedir 
seus comentários e contribuições. 


As pessoas são aquelas com pouco poder, mas alto interesse 
em seu produto. Eles não têm o poder de vetar ou alterar 
decisões, mas têm um profundo interesse em seu produto. Em 
algumas empresas, podemos pensar no suporte ao cliente, 
vendas e marketing como exemplos de áreas que 
desempenham o papel de pessoas. Elas têm grande interesse, 
mas não têm o poder de mudar seu produto. Você pode se 
comunicar com eles por e-mail semanal de status e 
demonstrações de produtos. É importante coletar suas 
opiniões, mas lembre-se de que eles não têm o poder de mudar 
suas decisões. 


Os definidores de contexto são aqueles com poder de mudar 
seu produto, mas pouco interesse em seu produto. Exemplos 
de áreas que podem desempenhar uma função de definidor de 
contexto são RH e Jurídico. Se o RH não ajudar você a formar 
a equipe, você não terá uma equipe para construir seu produto. 
Se o Departamento Jurídico não estiver ciente e alinhado com 
os aspectos legais de seu produto, ele tem o poder de bloquear 
ou atrasar seu lançamento. Um CFO e um controlador também 
são duas funções que têm o poder de mudar decisões que 
afetam seu produto. É importante manter os definidores de 
contexto bem informados sobre as decisões do produto. 
Consulte-os antes de tomar decisões importantes. Mantenha-os 
informados semanalmente. 


e A multidão é quem tem baixo poder e pouco interesse. Mesmo 
que eles tenham pouco poder e interesse, é importante mantê- 
los informados. Normalmente, uma atualização mensal sobre o 
andamento do produto é suficiente. Pode ser por e-mail ou em 
uma reunião geral mensal com demonstrações de produtos 
como vou comentar mais adiante. Normalmente são as pessoas 
das áreas de RH, Jurídico, Administrativo e Financeiro que não 
estão no grupo de definidores de contexto. 


É importante observar que cada empresa tem sua própria dinâmica, 
portanto, uma área ou pessoa que desempenha uma função 
específica na matriz de poder-interesse de uma determinada 
empresa pode ter outra função em uma empresa diferente. 


25.3 Empatia 


Essas duas ferramentas são muito úteis para o head de produto 
poder entender melhor como se relacionar com seus stakeholders e 
como gerenciar suas expectativas, o que, como eu já disse, vai 
tomar de 50% a 80% de seu tempo. 


A empatia é uma ferramenta fundamental para o head de produto 
poder gerenciar seus stakeholders. Como comentei no capítulo 
Desenvolvendo o time e gerenciando expectativas, empatia é a 
capacidade que uma pessoa tem de se colocar no lugar de outra 
para compreender os suas expectativas. Seus anseios, motivações, 
necessidades e problemas. 


Essa característica é importante para que o head de produto 
entenda os clientes e usuários do produto, saber como estes se 
relacionam com ele, e que problema esperam resolver ou que 
necessidade querem ver atendidas. Também ajuda a entender o 
impacto de seu produto no seu time e nas pessoas de outras áreas. 
Por fim, mas não menos importante, o head de produto também 


precisa se colocar no lugar dos donos do produto, para entender 
suas expectativas e os resultados que ele trara para a empresa. 


25.4 Resumindo 


e O gerenciamento de expectativas é algo entre 50 a 80% do 
tempo de um head de produto. 


e RASCI é uma ferramenta muito útil para ajudar a definir e 
entender os papéis e responsabilidades de cada pessoa e cada 
função. 


e A matriz de poder-interesse, juntamente com RASCI, é uma 
ótima ferramenta para ajudá-lo a entender melhor e interagir 
com seus stakeholders. 


e Mas não se esqueça, a principal ferramenta que um head de 
produto precisa para entender melhor e, consequentemente, ter 
interações aprimoradas e frutíferas com seus stakeholders é a 
empatia. 


No próximo capítulo vamos entender mais sobre como contratar 
pessoas para o time. 


CAPITULO 26 
Contratar as pessoas certas 


Como comentei no capítulo Pessoas: prioridade n° 1, sempre nós 
gastamos dinheiro e energia para adquirir e reter as melhores 
pessoas. Ter as pessoas como a prioridade número 1 é a chave 
para atingir qualquer outro objetivo. E o primeiro passo para ter as 
melhores pessoas no seu time é a contratação. 


O trabalho de contratação de pessoas deve ser feito em conjunto 
com o RH. É um trabalho em equipe. Já vi situações em que esse 
processo é totalmente delegado para o time de RH, e a pessoa que 
está contratando fica apenas perguntando "cadê os candidatos?" e 
"por que o RH está demorando tanto para preencher essa vaga?". 
Definir perfil, encontrar candidatos, entrevistar, selecionar, fazer 
onboarding é tanto responsabilidade do RH quanto do head de 
produto e de seu time. 


Definir o perfil 


O primeiro passo para contratar as pessoas certas para o seu time é 
definir o perfil de quem você está procurando para se juntar ao time. 
Quando falo de perfil, estou pensando não só em conhecimento 
técnico como também em senioridade comportamental e fit cultural, 
ou seja, que valores a pessoa precisa ter para trabalhar nesse time. 
É importante construir esse perfil em colaboração com mais 
pessoas do time. Desse perfil, sairá a descrição da vaga, ou job 
description em inglês. 


Atrair candidatos 


Tendo o perfil definido, é preciso anunciar a vaga a trazer 
candidatos. É o trabalho de atração de pessoas. Aqui o marketing 
pode ajudar. Da mesma forma que precisamos contar ao mundo 
sobre o problema que resolvemos com nossos produtos e como o 


produto o resolve para encontrar as pessoas certas que terao 
interesse em virar nossos clientes, precisamos contar ao mundo 
sobre o tipo de pessoa que precisamos em nosso time. 


Para isso, é importante fazer um trabalho de employer branding, que 
é contar por que a sua empresa é uma empresa interessante na 
qual trabalhar. Contar nas redes sociais e em eventos sobre os 
trabalhos feitos pelo time, os desafios e as conquistas, como é o 
ambiente e a cultura do time. Isso tudo faz parte do employer 
branding e ajuda a atrair pessoas interessadas em trabalhar no seu 
time de desenvolvimento de produto. Esse é um trabalho feito em 
parceria entre RH, marketing e o time de desenvolvimento de 
produto. 


Outra excelente fonte de novas candidaturas são as indicações 
internas. Peça para as pessoas do time indicarem pessoas com 
quem trabalharam em outros lugares e com quem eles gostariam de 
trabalhar de novo. É possível inclusive incentivar essas indicações 
dando prêmios para quem indicou caso a pessoa indicada seja 
contratada. 


26.1 Entrevistar 


É importante ter a sequência de entrevistas bem definida. Quem são 
as pessoas que vão entrevistar? Em que ordem? Serão entrevistas 
individuais ou em grupo? Haverá resolução de caso? Normalmente, 
nas empresas em que trabalhei, a primeira entrevista é feita pelo 
RH, para apresentar a vaga e a empresa e para entender um pouco 
mais do perfil comportamental da candidata. O RH pode usar algum 
teste comportamental para isso. 


Em seguida, vêm as entrevistas com as pessoas do time de 
desenvolvimento de produto. Se for uma contratação para uma 
posição que vai interagir bastante com outras áreas da empresa, é 


importante que a candidata também seja entrevistada por pessoas 
dessa outra área. Normalmente sugiro que o líder direto seja o 
primeiro a entrevistar, em seguida que a pessoa seja entrevistada 
por pares do time de desenvolvimento de produto e de outras áreas, 
se for o caso. 


Se a pessoa for liderar um time, sugiro a oportunidade de algumas 
pessoas do time também entrevistarem. Apesar de deixar o 
processo mais longo, acho interessante mais pessoas entrevistarem 
por dois motivos: primeiro, dá a oportunidade de mais gente 
conhecer os candidatos e, quando a decisão for tomada, mais 
pessoas estarem comprometidas com o sucesso desse novo 
membro do time; segundo, dá a oportunidade de a candidata 
conhecer melhor a empresa e as pessoas que compõem o time. 


Uma dica importante para quem entrevista é procurar fazer as 
mesmas perguntas para todos os candidatos, assim você poderá 
comparar as respostas para escolher aquela que mais se encaixa 
no perfil que você está buscando. Em relação a que tipo de 
perguntas fazer, costumo ouvir a história da pessoa e perguntar 
sobre acertos, erros, relação com outros membros do time e com 
pessoas de outras áreas. 


Durante o processo de entrevistas, pode ser interessante pedir para 
a candidata resolver um problema em casa para depois ela 
apresentar a solução. Esse processo é bastante comum tanto em 
vagas de gestão de produto, como de UX e de engenharia. O 
objetivo desse teste é conhecer melhor a capacidade de resolução 
de problemas, bem como de apresentação de soluções. E essa 
apresentação da solução é uma boa oportunidade para entender 
como a pessoa se expressa e como ela lida com questionamentos. 


Acho interessante o caso a ser resolvido ser um caso prático da 
empresa, em que o time está trabalhando ou pretende trabalhar em 
algum momento. Já ouvi críticas de que isso é consultoria gratuita e 
que depois a empresa vai usar a melhor solução. É importante 
deixar claro que a resolução de case tem dois objetivos, dar a 


oportunidade de as pessoas que estao contratando conhecerem 
melhor o candidato, como ele resolve problemas e apresenta suas 
solugdes, assim como dar ao candidato a oportunidade de conhecer 
que tipo de problemas ele vai encontrar no dia a dia. 


Vale ressaltar que ao pedir uma resolução de caso, há o perigo de 
perder candidatos. Por isso, é importante deixar claro que o 
processo terá essa fase, e é importante encantar o candidato antes 
de apresentar o caso a ser solucionado para deixá-lo com vontade 
de resolver o caso. 


Como comentei, esse é um processo longo, com várias entrevistas 
e testes, o que pode fazer você perder boas candidaturas. Por isso, 
é importante manter esse processo atraente, contar à candidata 
como ela está indo, em que fase ela está e o que falta para chegar 
ao final do processo. Já ouvi relatos de empresas que conseguem 
fazer esse processo todo em um dia, chegando ao final do dia com 
candidatos recebendo uma proposta, mas nunca tive a oportunidade 
de presenciar um processo assim. 


Escolher e fazer a proposta 


Após as entrevistas e os testes, chegou o momento de escolher a 
melhor candidata. A melhor forma de fazer isso é juntando as 
pessoas que entrevistaram os candidatos para contarem suas 
impressões sobre cada um, assim a líder da vaga pode tomar a 
decisão sobre quem escolher. A decisão de quem contratar é da 
líder que tem a vaga aberta, mas esse momento para trocar 
percepções é importante. Costumo chamar essa reunião de comitê 
de contratação, que dá a oportunidade não só de escolher o melhor 
candidato, como de entender melhor como as pessoas estão 
fazendo o processo de entrevista e, eventualmente, alinhar alguns 
pontos em relação a esse processo. Isso deixa os membros do time 
mais engajados com o sucesso da pessoa que será contratada. 


Uma vez definida quem é a pessoa, é preciso desenhar a proposta 
que será feita para ela. E importante que a proposta seja 


financeiramente relevante. Não é comum a pessoa aceitar receber 
menos do que ela está recebendo atualmente. E é importante 
balancear incentivo de curto prazo (salário e benefícios), médio 
prazo (bônus) e longo prazo (stock options e similares). Cuidado 
para não fazer uma oferta que seja muito discrepante com o que as 
pessoas atuais do time já têm, para não criar diferenças que podem 
minar o trabalho em equipe. 


Onboarding 


Supondo que a candidata aceitou a proposta, chegamos a uma 
nova fase do processo, o de onboarding, ou seja, o de trazer a 
pessoa para o time e fazê-la parte desse time. O RH vai cuidar da 
parte mais burocrática desse processo, mas é preciso também 
desenhar com o RH todo o onboarding para garantir que a 
contratada se sinta acolhida e entenda mais sobre a empresa, o 
time e os desafios que ela terá pela frente. 


Na Conta Azul tínhamos um processo muito bacana de onboarding, 
coordenado pelo RH, onde todos os novos funcionários passavam 
por uma semana de imersão para conhecer todas as áreas da 
empresa e os principais membros dessas áreas. Em seguida, as 
pessoas tinham um onboarding local, no time do qual elas fariam 
parte. No Gympass, além do onboarding, todas as pessoas eram 
convidadas a participar de algumas ativações, que era o momento 
em que íamos a um cliente para apresentar o benefício do Gympass 
para seus funcionários. É importante dar à nova pessoa que está 
entrando no time a oportunidade de conhecer mais sobre as outras 
áreas da empresa e sobre o cliente, antes de ela começar a 
trabalhar. 


Conversas do RH com a pessoa após 45 e 90 dias que a pessoa foi 
contratada podem ajudar a perceber pontos de melhoria nesse 
processo de onboarding. Esses primeiros dias da pessoa no seu 
novo time são fundamentais para o sucesso da relação futura, por 
isso é importante monitorar de perto. 


Feedback 


O titulo deste capítulo é Contratar as pessoas certas, mas não basta 
só contratar, é preciso também cuidar das pessoas durante todo o 
tempo que ela estiver no time. 


Escrevi um capítulo inteiro sobre Feedback e avaliação de 
desempenho, mas quero pontuar aqui, pois feedback é algo muito 
importante para as pessoas que fazem parte do seu time. Como 
elas poderão saber que estão no caminho certo? No que elas 
podem melhorar? O que eles estão fazendo e que devem continuar 
fazendo? O que elas não estão fazendo e que deveriam fazer? O 
que elas estão fazendo e que elas deveriam parar de fazer? 


É muito importante deixar claro para cada pessoa do seu time sobre 
esses pontos. E é muito importante lembrar que feedback é uma via 
de mão dupla, ou seja, você também deve procurar saber o que 
você pode fazer para ajudar a pessoa. 


Encerrando um ciclo 


Eventualmente você pode tomar a decisão de desligar alguém, o 
que é conhecido como turnover involuntário, ou alguém do seu time 
pode tomar a decisão de sair do seu time, o turnover voluntário. 
Esse sempre é um momento difícil, de ruptura, mas importante 
entender os motivos que acabaram fazendo chegar nessa decisão. 
Poderia ser evitado? Se inevitável, poderia ter acontecido de uma 
maneira mais planejada, evitando disrupção para o time? 


26.2 Resumindo 


e O trabalho de contratação de pessoas deve ser feito em 
conjunto com o RH. E um trabalho em equipe. 


e As fases da contratação são definir o perfil, atrair candidatos, 
entrevistar, escolher e fazer a proposta, onboarding. 


e O ciclo de vida de uma pessoa no seu time não termina no 
onboarding. É importante constantemente dar e receber 
feedback dela, para garantir que o relacionamento funcione 
bem tanto para o time quanto para a pessoa nova no time. 


e Por fim, a última fase do ciclo de vida da pessoa no time é 
quando a pessoa sai do time. É preciso entender os motivos 
que levou a essa decisão para entender como esses temas 
podem ser trabalhados no futuro. 


No próximo capítulo, vamos entender como fazer feedback e gestão 
de desempenho. 


CAPITULO 27 
Feedback e avaliação de desempenho 


Uma das principais ferramentas para desenvolvimento das pessoas 
do seu time é o feedback. Essa palavra é um termo inglês que 
originalmente significa "retroalimentagao", ou seja, um processo em 
que as ações de um determinado sistema são inseridas de volta no 
sistema para o aprimoramento do próprio sistema. Na gestão de 
pessoas, o feedback é quando uma pessoa conta para outra como 
seu comportamento e suas ações foram percebidos por essa 
pessoa. Feedback pode ser dado por pares, por subordinados ou 
por líderes. 


Feedback 


Como líder, é muito importante você dar feedback sempre que 
necessário para as pessoas que trabalham com você. Seis aspectos 
são essenciais para que o feedback possa ser o mais útil e 
relevante possível: 


e Ser necessário: antes de dar um feedback, é importante 
entender se ele é necessário. O que a pessoa fez afeta o 
resultado negativamente? Ou é somente uma forma diferente 
de fazer o que precisa ser feito? Às vezes, damos feedback 
sobre algo porque foi feito de uma forma diferente do que 
esperávamos, mas não necessariamente gerou resultados 
ruins. Se o resultado foi atingido no mesmo tempo, de uma 
forma aceitável, precisamos aceitar essas diferentes formas de 
se fazer as coisas e de se obter os resultados. 


e Na hora: é importante dar o feedback o mais próximo possível 
do momento em que a situação sobre a qual você quer dar 
feedback aconteceu. Dessa forma, os detalhes sobre o ocorrido 
e as motivações que levaram as pessoas a agirem da forma 
como agiram estarão frescos na memória de todos. 


e Objetividade: ao conversar sobre o que aconteceu, seja 
objetivo, ou seja, vá direto ao ponto e baseie seu feedback em 
fatos. O seu feedback deve ser útil para a pessoa que está 
recebendo, ele deve dar claras indicações sobre o 
comportamento esperado para aquela situação. 


e Transparência: o feedback tem que ser transparente, não pode 
haver aspectos escondidos ou não ditos, contanto que sejam 
aspectos relevantes para aquele feedback. 


e Empatia: ser transparente e objetivo não significa ser rude. Ao 
contrário, o feedback tem por objetivo ajudar a pessoa a 
entender como suas ações e seu comportamento impactam as 
outras. Coloque-se no lugar dessa pessoa que vai receber esse 
feedback e pense em como você gostaria de recebê-lo para 
que ele seja o mais útil possível. 


e Privado: procure dar o feedback em um ambiente privado, para 
dar espaço e liberdade para uma conversa transparente e 
produtiva. 


27.1 Características de uma boa gestora de 
produtos 


Eu costumo avaliar gestores de produtos em relação a 7 principais 
características: 


Empatia: é a capacidade que uma pessoa tem de se colocar no 
lugar de outra para compreender os seus anseios, motivações, 
necessidades e problemas. Essa característica é importante para 
entender os clientes e usuários do produto, saber como estes se 
relacionam com ele e que problema esperam resolver ou que 
necessidade querem ver atendidas. Isso ajudará a gestora de 
produtos a entender melhor seu usuário para poder, junto com o UX 


e a engenharia, desenhar o melhor produto. Contudo, a empatia nao 
deve ser usada apenas com o cliente ou usuario. A gestora de 
produtos deve usa-la também no seu relacionamento com todas as 
areas da empresa, e deve entender o impacto que seu produto tem 
no trabalho delas. 


Comunicação: para poder ter empatia, é necessário que a gestora 
de produtos se comunique com as pessoas nos mais diferentes 
cenários: em conversas um a um e em pequenos grupos, ou 
fazendo apresentações para grupos pequenos e grandes de 
pessoas, apresentações que podem ser internas (dentro da 
empresa) ou externas (em conferências, grupos de usuários etc.). 
Porém, não é só de falar que vive o gestor de produtos. 
Comunicação é uma via de mão dupla, ou seja, a gestora de 
produtos tem de ser muito boa em saber ouvir e compreender o que 
os outros estão dizendo, e entender os anseios e as necessidades 
deles; o que tem a ver com a primeira característica, a empatia. 


Gestão do tempo: o dia a dia de uma gestora de produtos pode se 
encher rapidamente de tarefas e ela precisa ser capaz de perceber 
e diferenciar o que é urgente do que é importante, para garantir que 
terá sempre tempo para conhecer mais sobre o cliente e o usuário 
de seu produto. 


Novas tecnologias: o gestor de produtos deve estar antenado 
sobre as novas tecnologias para saber como ela pode impactar o 
seu produto. Acesso via smartphone, como isso impacta o produto? 
O usuário quer acessar via smartphone”? Para fazer o quê? Redes 
sociais, como o produto pode tirar proveito delas? Bancos de dados 
não relacionais, quais os benefícios e as deficiências? Go, a nova 
linguagem de programação do Google, no que ela é melhor do que 
a linguagem usada no produto? E no que ela é pior? Smartwatches, 
smartglasses, como isso impacta o produto? Como o usuário espera 
interagir com o produto nessas novas interfaces? 


Habilidades empresariais: o gestor de produtos deve se preocupar 
se o seu produto está atingindo os objetivos de negócio. Se o 


objetivo for margem, a receita e os custos estao sob controle? Se o 
objetivo for só receita, como esta o crescimento dela? Se o objetivo 
for número de usuários, como está evoluindo essa métrica? Além 
disso, o gestor de produtos deve entender como cada área da 
empresa funciona e como o produto afeta essas áreas. Como o 
jurídico funciona? Como o produto impacta no departamento 
jurídico? E como o departamento jurídico impacta no produto”? 
Essas perguntas podem ser repetidas para todas as áreas da 
empresa: suporte, operações, financeiro, RH, marketing, vendas, 
engenharia e UX. 


Curiosidade aguçada: a gestora de produtos precisa ter a 
capacidade de aprender rápido para poder ter insights e fazer 
julgamentos sobre o produto. Deve ser capaz de aprender tanto o 
lado soft do produto (qual é a motivação de negócio, qual problema 
do cliente o produto resolve etc.) como o lado mais técnico (qual 
tecnologia usamos, qual o impacto dessa tecnologia, que métricas 
podemos obter etc.). 


Tema do produto: por fim, mas não menos importante, a gestora 
de produtos precisa conhecer sobre o tema do produto. Se for um 
produto médico, o gestor de produtos deverá entender um pouco 
sobre medicina. Se for um produto financeiro, deverá conhecer um 
pouco de finanças. Por exemplo, na Locaweb, temos produtos mais 
técnicos (como o Cloud Server) e menos técnicos (como a Loja 
Virtual). A necessidade de conhecimento técnico é bem diferente 
nesses dois produtos. A gestora de produtos do Cloud Server 
deverá conhecer bem a fundo questões técnicas, enquanto o gestor 
de produtos da Loja Virtual não precisa ter tanto conhecimento 
técnico, mas deverá saber bastante sobre questões de venda 
online. 


27.2 Gestor de produtos precisa saber 
programar? 


Essa é uma pergunta razoavelmente polêmica. Como dito, a 
depender do tema do produto, é importante saber programar, 
principalmente se aquilo de que o gestor de produtos cuida é um 
produto mais técnico. Alguns exemplos da Locaweb são 
Hospedagem de Sites, Cloud Server e SMTP. Contudo, mesmo 
empresas que não "vendem" um produto técnico podem ter uma 
parte de seu produto com um viés mais técnico. Na Conta Azul 
tínhamos as APIs, as integrações com fintechs (lugu e Stoce) e a 
integração com as Secretarias da Fazenda para emissão de nota 
fiscal, e no Gympass toda a parte de integração com sistemas de 
gestão de academias e com sistemas de RH. Para esses produtos, 
é importante ter um gestor de produtos com conhecimento de 
técnico, uma vez que o principal usuário do produto será técnico e o 
objetivo do produto é um objetivo técnico. 


Por outro lado, um produto como Lova Virtual, o app do Gympass ou 
o portal de busca de imóveis da Lopes são produtos feitos para 
qualquer pessoa utilizar. Será que para esses produtos seria bom o 
gestor de produto ter conhecimento técnico, ou seja, saber 
programar? Na minha visão, não é essencial que o gestor de 
produtos tenha conhecimento técnico, mas certamente vai ajudar. O 
conhecimento técnico ajuda a entender como o produto é feito, e 
isso O ajudará a ser um gestor de produtos melhor. Ajuda a entender 
o trabalho feito pelo time de engenharia e pode ser útil nas decisões 
sobre priorização e escopo. Duas analogias que podem ajudar a 
entender melhor o benefício que saber programar traz para um 
gestor de produtos: 


e Um bom corredor de Fórmula 1 não precisa saber como o 
carro funciona, mas se ele souber, certamente poderá usar 
esse conhecimento para ser um piloto melhor. 

e Da mesma forma, uma guitarrista não precisa saber cantar 
nem tocar baixo, bateria, ou piano para ser uma boa guitarrista, 
mas certamente esse conhecimento adicional pode ajudá-la a 
ser uma guitarrista melhor. 


Isso nao significa que a gestora de produtos precisa ser uma expert 
em programação. Se ela nao tem nenhum conhecimento de 
programação, seria interessante fazer um curso introdutório à lógica 
de programação e experimentar fazer seu primeiro programa. Essa 
experiência só vai beneficiar a carreira dessa pessoa. 


SQL 


Se o gestor de produtos ainda não sabe, deve aprender SQL. 
Acesso aos dados está cada vez mais democrático nas 
empresas e saber SQL é fundamental para que o gestor de 
produtos possa usufruir dos dados de maneira independente, 
sem precisar ficar pedindo para outras pessoas criarem seus 


gráficos e dashboards. Quando colocamos o Metabase como 
solução de democratização dos dados na Conta Azul eu fiquei 
tão animado que passei uma semana inteira indo dormir às 2:00 
da manhã, pois ficava criando gráficos e dashboards para 
entender melhor como os produtos do Conta Azul eram 
utilizados. 





27.3 Avaliação de desempenho 


Muitas empresas utilizam a avaliação de desempenho como a 
ferramenta oficial da empresa para coletar e registrar o feedback 
dos seus funcionários. Líderes avaliando as pessoas do seu time. 
Pessoas avaliando os seus pares e seus líderes. Pessoas fazendo 
autoavaliações. 


Algumas empresas utilizam a matriz 9-box que tem duas 
dimensões: 


e Desempenho: análise do passado, dos resultados entregues 
por aquela pessoa. Aqui, mais do que o resultado em si, é 


importante levar em conta o papel da pessoa no atingimento 
desse resultado, principalmente se considerarmos resultados 
de um time de desenvolvimento de produtos, que são um 
resultado de equipe. 


e Potencial: análise do futuro, ou seja, o quanto a pessoa está 
preparada para lidar com novos desafios. Literalmente, 
potencial significa "ter ou mostrar a capacidade de se tornar ou 
se desenvolver em algo no futuro". Como dá para perceber, 
essa dimensão de avaliação de uma pessoa pode ser bastante 
subjetiva. Por esse motivo, algumas empresas têm substituído 
o potencial por cultura, ou seja, uma análise de como os 
resultados foram atingidos por aquela pessoa, e se estão 
alinhados com os valores da empresa. Tende a ser um pouco 
subjetivo também, mas um pouco menos do que potencial. 


Líderes fazem a avaliação de seus liderados com base nessas duas 
dimensões. Em algumas empresas, essas avaliações incluem, com 
um peso menor, a autoavaliação, as avaliações de pares, clientes 
internos e, caso a pessoa lidere um time, de seus liderados. É a 
avaliação 360º. Em outras empresas, a autoavaliação e as 
avaliações de pares, clientes e liderados servem como dados 
adicionais para o líder fazer a avaliação, mas não entram no cálculo 
da avaliação. 


Depois de feita a avaliação, normalmente se faz um processo de 
calibração, onde os líderes comparam a avaliação de seus liderados 
para entender se os critérios de avaliação usado por cada líder está 
equalizado. Esse processo todo de avaliação é liderado e 
coordenado pelo time de RH da empresa, e essa calibração é 
facilitada por alguém do RH. As pessoas avaliadas são plotadas na 
matriz 9-box e com isso tem-se um mapa das pessoas da empresa. 
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Figura 27.1: Matriz 9-box e seus quadrantes (fonte: https://grougp.com.br/blog/matriz-9- 
box/) 


Com essa avaliação calibrada em mãos, o gestor retorna para o 
liderado e então se inicia o trabalho de gestão de consequências, 
que é trabalho que precisa ser feito após o liderado receber sua 
avaliação: 


e Bem avaliados: pessoas que ficam em um dos 4 quadrantes 
superiores são as que foram bem avaliadas. Normalmente são 
as pessoas que são consideradas para aumentos e promoções. 
Normalmente elas ficam felizes com o feedback e se sentem 
motivadas a continuarem fazendo o trabalho da melhor forma 
possível. Contudo, se a autoavaliação da pessoa for superior à 
avaliação recebida, mesmo ela estando bem avaliada, há o 
risco de ela sentir alguma frustração. Isso só não acontece se 
ela for avaliada no quadrante superior direito da matriz 9-box. 


e Mal avaliados: pessoas que ficam em algum dos 3 quadrantes 
da esquerda ou algum dos 3 quadrantes superiores estão 
abaixo do esperado em desempenho e/ou em potencial (ou 


valores, se na empresa houve a decisao por trocar esse eixo da 
matrix 9-box). Essas pessoas precisarao fazer algo para serem 
bem avaliadas no próximo ciclo. Essa situação pode causar 
certo desconforto na pessoa avaliada por ela sentir que seu 
emprego pode estar em risco. Para algumas pessoas, essa 
situação pode servir de incentivo para ela buscar melhorar e, de 
fato, ser melhor avaliada no próximo ciclo. Por outro lado, 
algumas pessoas podem se sentir desmotivadas com essa 
avaliação e decidem procurar alguma oportunidade em outra 
empresa. Esta situação se agrava se a pessoa se autoavaliou 
melhor do que a avaliação que recebeu. 


Crítica ao processo de avaliação de desempenho 


O processo de avaliação de desempenho procura classificar os 
funcionários de uma empresa com o intuito de facilitar o 
entendimento de quem são as melhores pessoas e quem são as 
pessoas que precisam melhorar. Contudo, como expliquei acima, há 
muitas oportunidades para frustração nesse processo de avaliação, 
especialmente quando há discordância entre a autoavaliação e a 
avaliação recebida. Essa frustração normalmente é potencializada 
pelo fato de o processo de avaliação ser passível de: 


e subjetividade: como medir o potencial de uma pessoa? Como 
medir sua aderência aos valores da empresa”? Como medir sua 
participação no atingimento dos resultados? 


e bias: distorção em função de diversos aspectos do julgamento 
do avaliador em relação ao avaliado. Normalmente, o avaliador 
lembra das ações mais recentes de um avaliado. É comum 
ações com consequência negativa serem percebidos de forma 
mais intensa do que ações com consequência positiva. 


Além disso, estamos entendendo e respeitando cada vez mais a 
diversidade humana, não só em questões físicas e de preferências, 
como também a diversidade de perspectiva, de história e de 
contexto. Tendo essa maior clareza sobre a diversidade humana, 


torna-se cada vez mais complicado encaixar todos as pessoas de 
uma empresa em somente 9 caixas baseadas em duas dimensões 
(potencial vs. resultados). Para entender melhor a complexidade das 
pessoas que compõem uma empresa, provavelmente precisaremos 
pensar de forma multidimensional. 


Por esses motivos, existe uma tendência mundial de abandonar o 
processo de avaliação de desempenho periódico e substituí-lo por 
conversas mais frequentes entre líder e liderado sobre carreira, 
performance, potencial e valores. Segundo algumas estimativas 
(https://hbr.org/2016/10/the-performance-management-revolution), 
mais de um terço das empresas americanas já abandonaram o 
processo de avaliação de desempenho periódico e adotaram essas 
conversas mais frequentes como alternativa. 


27.4 Retrospectiva, alternativa ao processo de 
avaliação de desempenho 


Em adição às conversas mais frequentes entre líder e liderado sobre 
carreira, performance, potencial e valores, acho importante a cada 6 
meses fazer uma retrospectiva junto com o liderado sobre o que 
aconteceu nesse período. Da mesma forma que em 
desenvolvimento de produtos temos cerimônias de retrospectiva, é 
um momento de revisitar o que passou e avaliar o que foi bem, o 
que pode melhorar e os desafios pela frente. 


Eu faço uma primeira versão, baseado no histórico que tenho com a 
pessoa. Caso haja um processo formal de avaliação de 
desempenho na empresa onde eu estiver trabalhando, uso essa 
oportunidade para fazer a retrospectiva e considero todas 
informações geradas através desse processo, autoavaliação, 
avaliação de pares, clientes internos e de liderados, se houver. 


Essa primeira versão tem 3 seções, pontos fortes, pontos a 
melhorar e desafios do próximo semestre, que contempla não só os 
principais objetivos para o próximo semestre como também foco nos 
pontos de melhoria. Caso haja um processo formal de avaliação de 
desempenho na empresa onde eu estiver trabalhando, coloque 
minha sugestão inicial de classificação nos quesitos mensurados 
nesse processo formal. 


O próximo passo é usar uma das reuniões de 1:1 para conversar 
com o liderado sobre essa retrospectiva, ouvir como ele a enxerga 
e, eventualmente, ajustar a retrospectiva de comum acordo com ele. 
É um excelente momento para ter uma conversa mais ampla e uma 
reflexão conjunta sobre o semestre que passou e sobre o que vem 
pela frente. 


Caso haja um processo formal de avaliação de desempenho na 
empresa onde eu estiver trabalhando, faço essa conversa antes de 
inserir os dados no sistema de avaliação da empresa, pois acho 
importante a avaliação conter essa retrospectiva construída em 
conjunto com o liderado. Caso haja sessões de calibração, aviso o 
liderado de que a avaliação ainda pode sofrer ajustes pela 
calibração e, após a calibração, conto de forma transparente o que 
aconteceu na calibração, para ajudar a pessoa a entender como 
outras pessoas a percebem. 


EXEMPLO 
Pontos fortes 


O primeiro semestre foi particularmente dificil para Felipa, com 
muitas incertezas e uma enorme pressao de entrega do 
Projeto Avengers. Diante disso tudo, Felipa conseguiu navegar 
muito bem pela situação e encontrar boas soluções, 
inclusive recomendando uma aquisição de empresa, como 
também manteve sua tribo engajada no processo. 


Pontos a melhorar 


Seu time de PMs ainda é júnior, com pouca experiência de 
gestão de produtos, apesar de ter bom conhecimento técnico do 
tema do produto. É importante buscar formas de acelerar essa 
senioridade do time. 


Desafios para o próximo semestre 


Deve trabalhar para aumentar senioridade de seus PMs pois 
eles ainda demandam bastante de seu tempo, impedindo-a de 
ter um papel mais estratégico. 





27.5 Promoções e aumentos 


No capítulo Contratar as pessoas certas comentei que, ao fazer a 
proposta para uma pessoa se juntar ao seu time, é importante 
balancear incentivo de curto prazo (salário e benefícios), médio 
prazo (bônus) e longo prazo (stock options e similares). De tempos 
em tempos, enquanto essa pessoa estiver no seu time, é importante 
avaliar se esses incentivos precisam ser revistos, ou seja, se ela 
merece um aumento ou uma promoção. Há dois aspectos 


importantes a considerar, quando e como dar aumentos e 
promoções. 


Quando 


É comum empresas que definem um período do ano para 
promoções e aumentos, normalmente logo após o período de 
avaliação de desempenho ou da retrospectiva periódica. 
Recomendo não fazer isso, pois na hierarquia de necessidades da 
maioria das pessoas, a necessidade por reconhecimento e 
recompensa financeira vem antes da necessidade por 
desenvolvimento pessoal. Sendo assim, se em uma mesma 
conversa colocarmos o tema sobre promoções e aumentos junto 
com o tema feedback e que pontos ela precisa para melhorar, a 
atenção da pessoa estará muito mais voltada ao tema promoções e 
aumento. Por esse motivo, recomendo separar essas duas 
conversas. Quando conversar sobre promoção e aumento, foque 
apenas nesse tema. E quando conversar sobre retrospectiva, 
novamente foque apenas nesse tema. 


Como 


Existem duas formas de promover uma pessoa. A primeira forma é 
esperar que ela esteja demonstrando habilidades de, pelo menos, 
70% do próximo nível de carreira para promovê-la. É o que chamo 
de “promoção empurrada”, ou seja, ela deve empurrar para 
conseguir sua promoção. A outra forma é avaliar o potencial da 
pessoa, Ou seja, se ela tem a capacidade de desenvolver as 
habilidades necessárias para operar no próximo nível de carreira e, 
se ela tiver, promovê-la. Chamo essa forma de "promoção puxada" 
pois a pessoa é puxada para operar no nível de habilidade do 
próximo nível de carreira. 


Tenho preferência pelo modelo de promoção puxada, pois gera um 
desafio bastante motivador para a pessoa, que sentirá que está 
devendo as habilidades necessárias e vai correr para desenvolvê- 
las o mais rápido possível. Há, obviamente, o risco de ela não 


conseguir desenvolver essas habilidades mas, na maioria dos 
casos, vejo que pessoas com potencial normalmente conseguem 
desenvolvê-las bem rápido. Já na promoção empurrada, a principal 
vantagem é que não há risco, a pessoa que é promovida já 
demostra as habilidades necessárias. Contudo, exatamente por já 
apresentar as habilidades necessárias, essa pessoa pode achar que 
a promoção não vem, ou está demorando muito e pode querer olhar 
o mercado aumentando o risco de você perdê-la do seu time, por 
demorar a dar o seu reconhecimento. 


27.6 Resumindo 


e Seis aspectos essenciais para um bom feedback são: checar se 
o feedback é necessário, dá-lo na hora em que acontece, ser 
objetivo, ser transparente, ter empatia e dar o feedback em 
privado. 


e As sete principais características de um bom gestor de produto 
são empatia, comunicação, capacidade de gestão do tempo, 
conhecimento de novas tecnologias, habilidades empresariais, 
curiosidade aguçada e conhecimento sobre o tema do produto. 


e Se o produto não for um produto técnico, não é necessário 
saber programar. Contudo, ter alguma noção de programação 
pode ser útil para entender como seu produto funciona. Saber 
SQL também é útil, pois ajudará a gestora de produtos a 
entender melhor as métricas de seu produto. 


e Processos formais de avaliação de desempenho têm sido vistos 
cada vez mais pelas empresas como algo que não traz tantos 
benefícios como esperado. Várias empresas estão substituindo 
esse processo por conversas mais frequentes entre líder e 
liderado sobre carreira, performance, potencial e valores. 


e Retrospectiva semestral é uma boa forma de ter uma conversa 
estruturada com o liderado sobre os resultados atingidos e 
como eles foram atingidos, e sobre os desafios que estão por 
vir. Essa retrospectiva deve ser construída em conjunto com o 
liderado. Caso haja um processo formal de avaliação de 
desempenho na empresa onde você estiver trabalhando, use o 
processo de retrospectiva para criar a avaliação de 
desempenho. 


e Sobre promoções e aumentos, há dois aspectos a considerar, 
quando e como. Recomendo separar as conversas de aumento 
e promoção das conversas sobre feedback para manter o foco 
total no tema de cada uma dessas conversas. Recomendo 
também promover a pessoa quando ela apresenta o potencial 
de desenvolver as habilidades necessárias para ocupar o 
próximo nível de carreira, e não esperar que ela já demonstre 
as habilidades necessárias para esse próximo nível de carreira, 
pois isso vai motivar mais a pessoa. 


No próximo capítulo vamos conhecer as cerimônias que costumo 
usar com os times que eu lidero. 


CAPITULO 28 
Cerimônias 


Neste capítulo, vou falar das cerimônias que costumo usar com os 
times que eu lidero. Essas cerimônias com diferentes stakeholders 
têm por objetivo planejamento, alinhamento e gestão de 
expectativas. Saliento que essa lista não é definitiva, ou seja, a 
depender da empresa e do contexto, pode ser interessante criar 
outras, e algumas das cerimônias listadas aqui podem não ser 
necessárias. Falarei sobre reuniões 1:1 (one on one ou one to one), 
reuniões de liderança, reuniões de All-Hands, Product Council, 
Product Update e reunião de estrutura de time. 


28.1 Reuniões de 1:1 


As reuniões de 1:1 são aquelas que o head de produto tem com 
seus liderados, sua líder, outros membros do seu time e com 
pessoas de outras áreas. 


Reunião 1:1 com liderados 


As reuniões de 1:1 com os liderados são, com certeza, uma das 
mais importante do head de produto. Devem ser semanais e de uma 
hora. Caso o head de produto não consiga fazer todas essas 
reuniões em uma semana e decida fazer quinzenalmente ou 
diminuir sua duração, é sinal de que o head de produtos está com 
muitos liderados. Apesar de ter uma hora, essa reunião não precisa 
necessariamente ocupar uma hora. Em algumas semanas, podem 
ocupar menos de uma hora, em outras, pode haver a necessidade 
de mais tempo. 


O tema dessa reunião é livre. Questões pessoais, questões do dia a 
dia, preocupações, feedbacks, retrospectivas. Não deve focar 
apenas em prestação de contas e relatório de progresso da pessoa. 
Durante essas conversas certamente aparecerão temas que 
deveriam ser conversados em conjunto com outras pessoas de seu 
time, então sugira mover o tema para a reunião de liderança. Uma 
vez por mês, no início de um novo mês, é importante dar uma 
passada nos OKRs para ver se tem algum impedimento em que 
você possa ajudar. 


Essa reunião pode ser feita em uma sala, ou em um café ou um 
restaurante para um almoço. Ou mesmo por vídeo, em casos de as 
pessoas não estarem no mesmo lugar. Já vi pessoas fazendo 1:1 
andando. Fica a seu critério e de seu liderado. 


Costumo anotar os temas à medida que lembro de um tópico a ser 
conversado em um documento compartilhado com o liderado. Divido 
esse documento em temas novos e, à medida que vamos 
conversando, anotamos alguns pontos sobre os temas para 
referência futura. Terminado o 1:1, marco a data quando ocorreu a 
reunião e abro uma seção de novos temas. 


Reunião com sua líder 


Você se reporta para alguém na organização, então é importante 
também manter uma cadência no mínimo semanal de conversas 
com essa pessoa. Essa reunião deve servir de alinhamento entre 
vocês dois, para garantir que essa pessoa lhe passe sempre o 
contexto da empresa e do produto que você lidera nessa empresa, e 
que ela o ajude a remover os impedimentos. 


Como head de produto, pode acontecer de você reportar para 
alguém que não tenha tanta experiência com gestão de 
desenvolvimento de produto como você. Por outro lado, essa 
pessoa terá experiência e conhecimento em outras áreas. É 
importante essa diferença de conhecimento e de experiência estar 


clara para ambos, para vocés poderem fazer essas conversas da 
forma mais proveitosa possivel para ambos. 


Sobre onde fazer, e como anotar, valem os comentarios que fiz 
acima sobre 1:1 com seus liderados. 


Reuniao com outras pessoas 


Além dos 1:1 com seus liderados e com seu lider que, como disse 
acima, devem ser semanais e de uma hora, vocé pode ter a 
necessidade de fazer 1:1 com outras pessoas do seu time e com 
pessoas de outras areas. Isso acontece porque a correria do dia a 
dia pode ser tao grande que nao sobre tempo para que essas 
conversas aconteçam se não estiverem agendadas. Avalie junto 
com cada uma dessas pessoas se existe a necessidade semanal, 
periódica ou apenas eventual para essas conversas. A duração 
também pode ser menor do que uma hora. 


Costumo ter a necessidade de 1:1 semanais com líderes de RH, 
para conversar sobre necessidades de contratação e gestão de 
pessoas do time de desenvolvimento de produto. Também costumo 
ter 1:1 semanais com a líder da área de marketing para falarmos 
sobre geração de demanda para produto e sobre marketing de 
produto, ou seja, sobre como contar ao mundo sobre o problema 
que o produto resolve e como nosso produto o soluciona. Com 
frequência menor que semanal, pode fazer sentido 1:1 com o líder 
de vendas, para falarmos sobre o processo de venda do produto, 
com o líder de operações, para entendermos os impactos 
operacionais do produto, e com a líder do financeiro, para 
entendermos as receitas e os custos gerados pelo produto e pelo 
time. 


28.2 Reuniões do time de liderança 


Reuniões do time de liderança são as reuniões que o head de 
produto faz com os seus liderados diretos. Além dos liderados 
diretos, é importante ter a pessoa de RH que está dedicada a ajudar 
o seu time. Se não tiver alguém dedicado de RH, traga a pessoa 
mais sênior do RH que tem estado mais próxima do time de 
desenvolvimento de produto. 


Essa é uma reunião de time, não do head de produto. Ou seja, 
devem ser discutidos temas trazidos por qualquer pessoa do time, e 
não apenas temas do head de produto. Ela pode acontecer mesmo 
que não estejam todos presentes. Mesmo quando o head do 
produto não está presente, ela deve acontecer normalmente. Caso o 
tema sendo discutido precise da presença de alguém que não está 
na reunião, deve-se aguardar para discuti-lo quando essa pessoa 
estiver na reunião. 


Os temas a serem discutidos podem ser colocados em um 
documento do Google Docs, compartilhado com todos as pessoas 
que participam da reunião. Qualquer pessoa pode colocar temas a 
serem discutidos. Podem ser os mais variados, desde que façam 
sentido serem discutidos com as pessoas presentes. Quando 
surgirem temas propondo para criar alguma nova rotina ou algum 
novo projeto que faça sentido ser executado, essa é uma excelente 
oportunidade para a head de produto delegar para alguma pessoa 
de seu time, que pode criar um subgrupo para lidar com o tema. 
Exemplos de temas assim são Design System, Hack Day, Plano de 
Carreira, entre outros. Alguns temas que devem aparecer 
periodicamente nessa reunião para serem discutidos com todos os 
líderes do time de desenvolvimento de produto: 


e OKRs: definição e acompanhamento de OKRs. Definição, uma 
vez por trimestre e acompanhamento pelo menos uma vez por 
mês, idealmente toda semana, para ver se não há algum 
impedimento que precise ser removido. 


e Product Council: falarei um pouco mais a frente neste capítulo 
sobre a Product Council, que é uma reunião trimestral de 


apresentação de planejamento do time de desenvolvimento de 
produto para a lideranca sénior da empresa. E importante 
planejar junto com o seu time o que vai ser discutido na Product 
Council. 


e All-Hands e Product Update: para essas duas reuniões, que 
são mensais, sobre as quais também falarei um pouco mais à 
frente, é importante definir junto com o time sobre os temas. 


e P&L: do inglês profit and loss ou receita e custo. É importante 
discutir com o time, pelo menos mensalmente, quanto de 
receita está sendo gerada com o produto e quanto o time de 
produto custa, incluindo não só pessoas como todos os outros 
custos (infraestrutura, treinamento, consultorias etc.). 


Antes de entrar no Gympass, eu costumava fazer essa reunião 
presencialmente uma vez por semana. Essas reuniões tinham uma 
hora de duração e, quando havia muitos temas, aumentávamos 
para 1,5 ou 2 horas para poder falar sobre todos os temas. No 
Gympass, como parte do time ficava em outros países, começamos 
a fazer a reunião remotamente, mas ainda uma vez por semana. 
Ainda no Gympass, quando começou a pandemia, decidimos mudar 
a cadência para diária, dado o volume de temas que tinham que ser 
discutidos em função da crise. Depois de algum tempo, tiramos a 
reunião de sexta-feira para criarmos um meeting free day, ou seja, 
um dia da semana sem reuniões. Quando me juntei à Lopes, por 
estarmos remotos e termos muito temas para conversar, optamos 
por fazer nossas reuniões diariamente. Quando percebermos que 
não há assunto suficiente para uma hora, vamos diminuir a 
frequência. 


Reunião de liderança do seu líder 


Além de coordenar sua reunião de liderança com seus liderados, 
muito provavelmente você participará da reunião de liderados do 
seu líder, que definirá o modelo e o ritmo dessas reuniões. Aproveite 
essas reuniões para fazer alinhamento com seus pares e seu líder. 


Traga temas de desenvolvimento de produto que possam ser 
relevantes para eles. Se houver espaço, essa é uma boa reunião 
para trazer esporadicamente algum dos seus liderados para expor 
algum tema. Com isso, você dará visibilidade para as pessoas do 
seu time, além de permitir a eles a oportunidade de interagir com 
outros líderes seniores da empresa. 


28.3 Reunião de All-Hands 


As reuniões de All-Hands são reuniões com todas as pessoas do 
time de desenvolvimento de produto, não só os seus liderados 
diretos. Além das pessoas do time de desenvolvimento de produto, 
devem participar também as pessoas de RH que trabalham junto 
com o time de desenvolvimento de produto e outros convidados tais 
como o CEO/founder, líderes de outras áreas e quem mais fizer 
sentido participar. 


O objetivo é comemorar os resultados, falar sobre lições aprendidas, 
discutir sobre o andamento dos OKRs, apresentar os novos 
membros do time e qualquer outro assunto que faça sentido 
conversar com todo o time. 


A frequência mais indicada é a mensal e é bacana fazer um happy 
hour com todo o time após a reunião para descontração. Caso a 
reunião seja remota, o happy hour também deverá ser remoto. 


28.4 Product Council 


O Product Council, ou conselho de produto é uma reunião com a 
liderança do seu time e a liderança sênior da empresa em que seu 
time apresente o planejamento do próximo trimestre e, na virada do 
ano, do próximo ano. O objetivo da product council é ter todos 


alinhados em relação aos objetivos a serem alcançados no próximo 
trimestre e nas métricas que contarão que esses objetivos estão 
sendo alcançados. 


Ela deve acontecer trimestralmente, por volta de uma semana antes 
de começar o novo trimestre. Nessa reunião, cada líder do time de 
desenvolvimento de produto apresenta seu planejamento do 
próximo trimestre para a liderança sênior da empresa. Muitas vezes 
o planejamento de 3 meses não contempla alguns temas que 
podem ser importantes para os participantes dessa reunião. Por 
esse motivo, tenho recomendado o uso do roadmap contínuo de 12 
meses (12-month rolling roadmap), que permite mostrar não só o 
que vem pela frente no próximo trimestre como também nos 
próximos 12 meses. O objetivo não é discutir se o que está no 
quarto trimestre deve vir antes do que está no terceiro trimestre, 
mas sim se o que está no quarto trimestre deveria ser trabalhado no 
próximo trimestre e, se sim, o que deve ser postergado. 


Roadmap Example 


3017 4017 


Jul E Aug Sep Oct Nov Dec Jan Feb Mar Apr Me 


Objectives 


Deliveries 
Team 2 Team1 





Constraints Discoveries 


Figura 28.1: Exemplo de 12-month rolling roadmap 


Note que, apesar de estarmos falando de roadmap, a primeira parte 
fala de objetivos e resultados. E fundamental manter a ordem de 
prioridade dos temas. Mais importante do que o que vai ser feito sao 
os objetivos que queremos alcançar e quais as métricas que 
indicam que estamos alcançando esses objetivos. É papel do head 
de produto relembrar dessa prioridade de discussão dos temas. 


Uma forma de mudar o foco para ficar 100% em objetivos e 
resultados é não usar roadmap e discutir apenas os OKRs. Tanto no 
Gympass quanto na Lopes tenho tido a oportunidade de participar 
em Product Councils muito produtivas, focadas exclusivamente em 
discutir os OKRs. 


A duração dessas reuniões depende da quantidade de temas a 
serem discutidos. Já cheguei a participar de reuniões de Product 
Council que tiveram que ser feitas em dois dias, dada a quantidade 
de temas e a necessidade de alinhamento necessário. Por outro 
lado, as reuniões mais curtas de Product Council que participei 
duraram entre 1,5 a 2 horas. 


A agenda da reunião começa com o head de produto fazendo uma 
introdução com informações sobre o contexto do planejamento do 
próximo trimestre e, em seguida, cada um dos líderes do time de 
desenvolvimento de produto apresenta o seu planejamento. 


Um ponto importante é fazer uma prévia da Product Council sem a 
liderança sênior da empresa, para dar a oportunidade dos membros 
do seu time se alinharem sobre seus planejamentos caso ainda não 
o tenham feito. Certa vez fiz uma Product Council sem esse 
alinhamento prévio e, no meio da apresentação do planejamento de 
uma pessoa, a outra comentou que ela "não pode ter planejado 
fazer aquilo pois X e Y não estão prontos e só serão entregues no 
final do trimestre", o que mostrava a falta de coordenação entre 
elas. 


Outro trabalho preparatório importante para a reunião de Product 
Council são reuniões 1:1 que podem ser feitas entre uma líder do 


time de desenvolvimento de produto e alguém da liderança sênior, 
para buscar feedback sobre o planejamento em um ambiente mais 
reservado e já levar o planejamento para a Product Council 
considerando esse feedback. A recomendação é fazer quantos 1:1s 
forem necessários para obter um bom alinhamento pré-Product 
Council. 


Product Council com clientes 


Uma variação da Product Council que pode ser interessante ser 
conduzida é a Product Council com clientes, ou seja, você convida 
alguns clientes para trabalhar com eles uma proposta de priorização 
para o próximo trimestre. Fizemos isso algumas vezes na Conta 
Azul, quando chamamos alguns de nossos contadores parceiros 
para passarem o dia conosco, para dar a eles a oportunidade de 
conhecer de perto nossa operação e, em uma determinada parte de 
dia, fazíamos um exercício de priorização com eles, onde 
elencávamos uma série de funcionalidades, cada uma com um certo 
custo de desenvolvimento, e os deixávamos escolher dentro de um 
limite de custo de desenvolvimento que eles poderiam aplicar. 


É muito bacana ver clientes passando pela mesma dificuldade que 
nós, gestores de produto, temos ao tomar decisões de priorização. 
Essa priorização feita pelos corretores servia como mais um insumo 
para nosso trabalho de priorização a ser preparada para o próximo 
trimestre e para ser apresentada na Product Council com a 
liderança sênior da empresa. 


28.5 Product Update 


Essa também é uma reunião mensal onde o time de produto 
apresenta para toda a empresa o que foi feito no último mês e o que 
está planejado para o próximo mês, sempre conectando com os 
OKRs do time. Essa é uma reunião muito importante para gestão de 


expectativas. Na Conta Azul, como tinhamos reuniao de All-Hands 
de toda a empresa todas as semanas, pegamos uma dessas 
reuniões para ser o product update. Ja no Gympass, as reuniões de 
All-Hands aconteciam uma vez por mês, então criamos uma reunião 
separada, cnamada de Global Product Update Call, que tinha que 
ser uma reunião remota já que o Gympass tinha na época times em 
14 países. 


Uma maneira de organizar o conteúdo é cada líder do time de 
desenvolvimento de produto apresentar sua parte ou, a cada mês, 
um dos líderes se responsabilizar por preparar e apresentar o 
conteúdo do mês. Além desse conteúdo, o head de produto deve 
fazer uma introdução e deve haver demonstrações das novas 
funcionalidades entregues. Idealmente, essas demonstrações 
devem ser ao vivo. Quanto mais demonstrações e menos slides, 
melhor. No último product update que participei na Conta Azul fiquei 
superfeliz pois foi 100% demonstrações. 


No final do product update é importante abrir para perguntas e 
respostas, e as respostas devem ser dadas pelos líderes do time de 
desenvolvimento de produto. 


Essa reunião é muito importante para "prestar contas” para a 
empresa sobre o que a área de produto está fazendo. 
Constantemente ouço que o time de tecnologia é uma caixa preta, 
“ninguém sabe o que eles estão fazendo e não entendemos o que 
eles falam". Para tirar essa percepção de caixa preta, o melhor 
caminho é a comunicação e o product update é um elemento de 
comunicação bastante eficaz. 


28.6 Reunião de estrutura de time 


Essa reunião pode acontecer de forma independente, ou ser uma 
parte da reunião de liderança do time. O objetivo é bem simples: 


decidir em conjunto com o time como sera organizado o time de 
desenvolvimento de produto, como será investido o orçamento para 
contratação de pessoas e qual a prioridade de contratação. Quais 
tribos e squads devemos montar? Será que devemos contratar só 
pessoas para engenharia, ou devemos também trazer designer e 
gestoras de produto? Devemos olhar o que temos para fazer, o que 
conseguimos fazer, e o que precisamos de ajuda. É uma reunião 
colaborativa, que o head de produto deve facilitar. 


É importante o pessoal de RH participar dessa reunião. Certa vez na 
Conta Azul, uma pessoa de RH que acompanhava a área de 
operações e de vendas pediu para participar dessa reunião para 
entender a dinâmica e ela ficou impressionada com a capacidade 
dos participantes da reunião em convergirem sobre a melhor forma 
de usar o orçamento. Foi quando ela comentou comigo que “o seu 
time é muito maduro para poder esse tipo de discussão. Lá na 
liderança de operações e vendas não temos essa maturidade para 
podermos implementar essa dinâmica", ao que eu respondi que no 
começo nós também não tínhamos essa maturidade, mas ela foi 
conquistada com o exercício constante dessa dinâmica, ou seja, O 
time foi ganhando maturidade à medida que aprendia a colaborar 
mais, a entender as necessidades dos outros líderes e a se 
perceber com um time com objetivo comum. 


28.7 Resumindo 


e Essas cerimônias com diferentes stakeholders têm por objetivo 
planejamento, alinhamento e gestão de expectativas. 
Saliento que essa lista não é definitiva, ou seja, a depender da 
empresa e do contexto, pode ser interessante criar outras e 
algumas das cerimônias listadas aqui podem não ser 
necessárias. 


e Reuniões de 1:1 são importantes para manter o alinhamento e 
a comunicação com seus liderados, seus líderes, outras 
pessoas do time e pessoas das outras áreas. 1:1 com seus 
liderados e seu líder devem ser semanais e ter reservada uma 
hora de conversa. Já os 1:1 com outras pessoas podem ter 
periodicidade e duração menor, ou mesmo ser eventuais. O 
tema dessas reuniões é livre, e não deve se ater apenas à 
prestação de contas. Envolvem questões pessoais, o dia a dia, 
preocupações, feedbacks, retrospectivas. 


e Reuniões do time de liderança são as reuniões que o head de 
produto faz com os seus liderados diretos. Além dos liderados 
diretos é importante ter a pessoa de RH que está dedicada a 
ajudar o seu time. O tema é livre, mas é importante discutir 
periodicamente sobre os OKRs e sobre as dinâmicas de 
comunicação com o restante da empresa. Devem ser no 
mínimo semanais. Podem acontecer mais de uma vez por 
semana, até mesmo diariamente caso haja muitos temas a 
serem discutidos. 


e All-Hands são reuniões com todo o time de desenvolvimento 
de produto onde são comemoradas as conquistadas e 
compartilhadas as lições aprendidas. A recomendação é que 
sejam mensais. 


e Product Council são as reuniões onde é apresentado o 
planejamento do próximo trimestre para a liderança sênior da 
empresa, preferencialmente no formato de OKRs. Costumam 
ser trimestrais. 


e Product Updates servem para tirar o efeito caixa preta dos 
times de produto e tecnologia. É quando os líderes desse time 
apresentam o que foi feito no último mês, o que será feito no 
próximo mês, como essas entregas impactam nos resultados 
da empresa, demonstrações das funcionalidades e abertura 
para qualquer pessoa possa perguntar o que quiser para o time. 


e Reuniao de estrutura de time serve para discutir junto com a 
lideranga do time de desenvolvimento de produto como o time 
sera organizado, como usaremos o orçamento de contratação e 
qual a prioridade de contratação. 


Com este capítulo, terminamos a parte Ill sobre ferramentas. No 
próximo capítulo, farei um grande resumo do livro para servir de 
referência rápida, com todos os "Resumindo" de todos os capítulos. 


CAPITULO 29 
Resumindo 


Neste capitulo transcrevi as seções Resumindo de todos os 
capítulos com o objetivo de criar um guia de referência rápida sobre 
todos os tópicos discutidos neste livro. 


29.1 Conceitos 


Comecei o livro estabelecendo algumas definições, fazendo uma 
revisão de conceitos básicos como produto e gestão de produtos, e 
apresentando novos conceitos como funções e responsabilidades 
de head de produto, estrutura de equipe, carreira e carreira Y para 
gerentes de produto. 


O que é produto digital e gestão de produtos 


e Produto digital é qualquer software que tenha usuarios. 


e Produtos digitais podem existir tanto em empresas digitais, em 
que o produto digital é o produto que a empresa vende, quanto 
em empresas tradicionais, que usam o produto digital para 
alavancar e potencializar o produto principal da empresa. 


e Recentemente começaram a surgir as empresas tradicionais 
nascidas digitais, ou seja, empresas que vendem um produto 
não digital, mas que têm o produto digital como parte crítica de 
sua estratégia desde o início da empresa. 


e Plataformas são produtos que entregam mais valor quanto 
mais usuários utilizam a plataforma, o famoso efeito de rede. 
Existem plataforma de um único lado e plataformas de múltiplos 
lados, que podem ser de troca, de conteúdo ou técnicas. 


e Gestão de produtos é a função responsável por conectar os 
objetivos estratégicos da empresa com os problemas e 
necessidades dos clientes. 


Papéis, responsabilidade e senioridade 


e O head de produto é responsável por coordenar a definição da 
visão e estratégia de produto, por ajudar os gestores de 
produto em seu desenvolvimento e por gerir as 
expectativas de todas as pessoas que têm interesse em seu 
produto. 


e Um conceito muito importante para ajudar uma head de produto 
com suas responsabilidades é o conceito de senioridade, que 
tem 3 dimensões, duas bem conhecidas, o tempo e o 
conhecimento e uma terceira não tão conhecida, mas tão 
importante quanto às outras, a senioridade de comportamento. 


Carreira de gestão de produtos 


e À carreira de produto tem a progressão de Associate Product 
Manager (APM) para Product Manager (PM) para Group 
Product Manager (GPM) para Chief Product Officer (CPO). 
Existem algumas variações de nomenclatura a depender da 
empresa e do país, mas em geral segue essa progressão. O 
importante é essa estrutura e progressão de carreira estarem 
claras para toda a empresa. 


e Quando se fala da liderança mais sênior de produto em uma 
empresa, há duas opções com seus prós e contras. Uma opção 
é a liderança única de todo time de desenvolvimento de 
produtos (PM, UX e engenharia), que funciona bem para times 
maiores, mas pode sobrecarregar quando são times de mais de 
100 pessoas. A vantagem é ter todo o time alinhado com uma 


unica liderança. A outra opção é a liderança compartilhada 
com CPO e CTO, que evita a sobrecarga em times grandes, 
mas pode causar uma diminuição de colaboração caso não 
haja boa sintonia entre esses dois ou mais líderes. 


e Para PMs que não querem seguir a carreira de gestão, é 
importante dar a opção da carreira em Y, com o papel de 
Principal Product Manager, que ajuda na integração e sincronia 
do trabalho dos diferentes times. 


Visão de produto 


e Apesar de ser apenas 10% do tempo de um líder de produto, 
definição de visão de produto é sua responsabilidade mais 
importante. Sem ela todo o trabalho de desenvolvimento de 
produto fica muito mais difícil. 


e A visão de produto nada mais é do que o entendimento de 
como será o seu produto no futuro. 


e Para fazer a visão de produto é preciso ter clareza sobre os 
objetivos da empresa com o produto, bem como entender 
profundamente os problemas e as necessidades que os clientes 
têm e que serão resolvidos pelo produto. 


e Os 6 passos para construir uma visão de produto são: obter 
objetivos estratégicos da empresa, obter entendimento dos 
problemas e necessidades dos clientes, desenhar primeira 
versão da visão, iterar e refinar, comunicar e revisar. 


Estratégia e objetivos 


e Estratégia de produto nada mais é do que o caminho que 
você vai seguir para chegar à sua visão de produto. 


e Para criar sua estratégia de produto você precisa ter bastante 
entendimento sobre seu mercado, ou seja, os concorrentes, o 
mercado potencial e acessível, o crescimento desse 


mercado, se existem disruptores e como esse mercado é 
regulado. 


e Utilize a análise SWOT para ajudar a definir que pontos você 
vai trabalhar em sua estratégia de produto. 


e Utilize OKRs para ajudar a definir os objetivos de sua estratégia 
e as métricas que dirão se você está no caminho correto. 


e Revise pelo menos anualmente, ou quando houver eventos 
relevantes no mercado, a sua estratégia e sua visão de produto. 
O mercado muda, seu produto evolui, então sua visão e 
estratégia de produto também deve evoluir. Os OKRs devem 
ser revistos trimestralmente. 


Estrutura de time 


e Times de desenvolvimento de produto são organizados em 
times mínimos, também chamados de squads, compostos de 
engenheiros, product designers e product managers. É 
importante deixar esses times o mais enxuto possível para 
ajudar em sua produtividade. Esses times mínimos são 
agrupados em times de produto chamados de tribos de 
produto. 


e Há 4 formas de se organizar os times de produto: por 
produto ou funcionalidade, por tipo de usuário, por jornada ou 
por objetivo. É possível também usar dois tipos diferentes de 
organização, criando uma organização híbrida. 


e Existem também as tribos estruturais, que criam a estrutura 
necessária para as tribos de produto performarem. Times que 
compõem as tribos estruturais são SRE/DevOps, Dados, 
Arquitetura/ Ferramentas/ Fundação, Design Ops, Segurança 
da Informação, Sistemas Internos, Engenharia de Vendas e 
Serviços Profissionais. 


A implementação da organização de time desenhada pode ser 
feita ou criando uma nova estrutura ou ajustando um time já 
existente. Em ambas as situações é importante conhecer bem a 
visão e a estratégia de produto para desenhar e implementar 
uma estrutura de time alinhada com ela. 


e À proporção mais indicada entre pessoas em engenharia e 
gestores de produto é de 7 +/- 2 engenheiros para cada gestor 
de produto. E de um product designer para cada gestor de 
produto. 


e Dois conceitos importantes no desenho de sua estrutura de 
time são o da Lei de Conway, que diz que as organizações 
tendem a criar sistemas que são uma cópia da estrutura de 
comunicação das empresas, e os 4 estágios de Tuckman de 
formação de times, formando, confrontando, normatizando e 
performando. 


e É possível também organizar times de produto por unidades de 
negócio que tenham outras funções além das compreendidas 
em um time de desenvolvimento de produto, tais como 
marketing, vendas e atendimento ao cliente. As motivações 
para criar unidades de negócio em vez de times de produto 
podem ser devido à aquisição, ou para dar mais agilidade ao 
novo negócio ou mesmo por se tratar de uma nova linha de 
produto completamente diferente do produto original. 


e O que faz um grupo de pessoas se comportar como um time 
são os objetivos comuns. 


Desenvolvendo o time e gerenciando expectativas 


e Para desenvolver seu time e gerir expectativas, o head de 
produto deve ter as 7 características de um bom gestor de 
produtos: empatia, comunicação, gestão do tempo, novas 
tecnologias, habilidades empresariais, curiosidade 
aguçada e tema do produto 


e Trés dessas caracteristicas sao essenciais para o trabalho de 
head de produto. Empatia para entender de onde vém as 
expectativas e que elementos precisam ser desenvolvidos em 
seu time. Comunicagao para poder entender e se fazer 
entender quando estiver conversando com as pessoas da 
empresa para gerir suas expectativas e quando estiver 
desenvolvendo seu time. Habilidades empresariais que 
ajudarao a entender os objetivos da empresa que sao 
componentes importantes das expectativas que as pessoas têm 
em relação ao produto. 


Antipadrões 


e Antipadrões são respostas comuns mas ineficazes de se 
resolver problemas. Existem muitos antipadrões bem 
documentados no mundo do desenvolvimento de produtos 
digitais. Os 4 antipadrões mais comuns em liderança de 
desenvolvimento de produto são documentação, foco em 
dados, grande reescrita e lista de desejos. 


e Documentação, que deveria ser mantida em um mínimo, para 
certos líderes chega a ser mais importante que o próprio 
produto. Nada pode ir para produção se não estiver 
devidamente documentado. 


e Foco em dados é quando toda e qualquer decisão tem que ser 
tomada com dados, sem levar em conta informações 
qualitativas, experiência prévia e intuição. 


e Grande reescrita acontece quando uma nova head de produto 
encontra um sistema escrito há algum tempo e identifica que 
será melhor reescrever do zero um novo sistema do que 
aprimorar o atual. 


e Lista de desejos vem da necessidade de o novo head de 
produtos de agradar a todos os stakeholders, focando o time de 
desenvolvimento de produtos a apenas implementar o que é 


pedido, delegando a priorização para as outras áreas da 
empresa. 


29.2 Princípios 


Aqui vimos meus princípios pessoais de liderança: 


e Pessoas: a prioridade nº 1, sempre. 
e Liderar é como ser um médico. 
Liderando sob pressão. 

Mentoria é uma via de mão dupla. 

e Como e quando delegar. 


Vimos também o que é cultura empresarial, um conjunto de 
maneiras de resolver problemas e reagir a situação compartilhadas 
por um grupo de pessoas trabalha junto. Por fim, vimos quatro 
valores que são o núcleo de todo time de desenvolvimento de 
produtos digitais. São eles que compõem a cultura de produto, que 
nada mais é do que o conjunto de comportamentos dos times de 
desenvolvimento de produtos digitais que produzem os melhores 
resultados: 


e Lançamento antecipado e frequente. 
e Foco no problema. 

e Entrega de resultado. 

e Mentalidade de ecossistema. 


Pessoas: prioridade nº 1, sempre 


e As pessoas são, e devem ser sempre, a prioridade número 
1 de qualquer empresa. Gastamos dinheiro e energia para 
adquirir e reter as melhores pessoas. Ter as pessoas como a 
prioridade número 1 é a chave para atingir qualquer outro 
objetivo. Isso não significa ser "bonzinho", dando tudo o que 
elas querem, e sim que devemos ser capazes de equilibrar os 


desafios que damos as pessoas para que possam melhorar 
continuamente. 


e A pessoas maçãs podres podem drenar e prejudicar seu time. 
Você deve ajudar essas pessoas a se encaixarem em seu time 
e, se isso não for possível, você deverá tomar a decisão mais 
difícil: tirá-la do time. 


Liderar é como ser um médico 


e Da próxima vez que você estiver em uma equipe, seja como 
parte dela ou desempenhando o papel de liderar a equipe, 
pense no papel de liderança semelhante ao do médico e no 
trabalho em equipe semelhante ao processo de cura realizado 
pelo corpo. Ajuda a entender as funções e responsabilidades do 
líder e das pessoas do time. 


Liderando sob pressão 


e Não existe um ambiente de trabalho sem pressão. Pessoas e 
equipes precisam da pressão externa (a meta, a data prevista, 
a falta de recursos) e também de dentro (motivação, drive, força 
interior) para existir e fazer as coisas, como um balão. 


e À pressão interna e a pressão externa precisam ser 
balanceadas com alguma tendência a ter um pouco mais de 
pressão do lado de fora para ter melhoria contínua. 


e Sob pressão, uma pessoa e uma equipe explodem ou ficam 
mais fortes. É papel do líder ajudar a pessoa ou a equipe a 
perceber isso e trabalhar em conjunto com eles para apoiar o 
aumento da pressão interna. 


Mentoria é uma via de mão dupla 


e Mentoria é um dos papéis mais importantes de um head de 
produto. E através da mentoria que um head de produtos ajuda 
seu time a se desenvolver. 


e Mentoria é uma via de mão dupla. A pessoa no papel de 
mentora deve estar aberta a novos aprendizados vindos de 
suas sessões de mentoria com sua mentorada. 


Como e quando delegar 


e Delegar é o ato de confiar uma tarefa e/ou uma 
responsabilidade a alguém. A liderança é um ato contínuo de 
delegação de tarefas e de responsabilidades. 


e Entre não delegar e delegar existem vários níveis de 
delegação que são usados de acordo com o contexto, ou seja, 
do problema a ser resolvido e quem estará trabalhando no 
problema. 


e O conceito de delegação anda de mãos dados com o conceito 
de microgestão, estilo de gestão em que o gerente observa ou 
controla de perto o trabalho de seus subordinados ou 
funcionários. 


e Existem diferentes maneiras de se fazer as coisas para se 
atingir o mesmo resultado. Líderes novos costumam achar que 
só o seu jeito de fazer é o certo. 


e Erros são oportunidades incríveis de aprendizado. Dai a 
importância em tolerar erros no trabalho. 


Cultura e valores 


e Cultura é a forma como um grupo de pessoas reage às 
situações do dia a dia. É papel do head de produto ajudar no 
desenho e na promoção da cultura da empresa para garantir 
um ambiente propício para o desenvolvimento de produtos de 
SUCESSO. 


e Tem cinco valores que acredito serem essenciais para ajudar a 
criar uma cultura que propicie o desenvolvimento de produtos 
de sucesso. Neste capítulo falei de 3 desses valores: não 


desperdice tempo buscando culpados, foque nos aprendizados. 
Nao compare situações de trabalho com guerra, ninguém quer 
matar ninguém. Lucro e receita são consequência, não deve ser 
o foco principal. 


Transparência, a fundação de um time de alta performance 


e Toda líder, para ajudar seu time a desempenhar melhor, precisa 
explicar o contexto e remover impedimentos. 


e Para podermos explicar o contexto, é fundamental sermos 
transparentes, explicar os números da empresa, explicar as 
motivações por trás de cada decisão, incluir o time nas 
decisões. 


e A transparência na gestão das empresas parece algo moderno, 
mas existe há algumas décadas. Dois exemplos interessantes 
vêm da década de 1980. Um em uma empresa americana 
chamada Springfield ReManufacturing Corp (SRC), que criou o 
conceito de gestão do livro aberto. O outro em uma empresa 
brasileira chamada Semco, do Ricardo Semler, onde Clóvis 
Bojikian, seu diretor de RH, implementou a gestão participativa. 
Ambas são da década de 1980 e são indústrias, ou seja, a 
vanguarda da gestão participativa. 


e Com transparência, é possível dar às pessoas as informações 
necessárias para que elas entendam o contexto e motivação do 
trabalho que estão fazendo e consigam tomar melhores 
decisões sobre esse trabalho. 


Diversidade, a base dos melhores produtos 


e Existem duas razões principais que motivam a construção de 
times de desenvolvimento de produtos digitais diversos. A 
primeira é que a diversidade traz novos pontos de vista. A 
segunda razão é que da mesma forma como o grupo de 


clientes que usa seu produto é diversa, sua equipe de 
desenvolvimento de produto também deve ser. 


e As pessoas têm diferentes origens, diferentes historias, 
diferentes conhecimentos. Devemos reconhecer e respeitar 
essas diferenças e entender que às vezes não chegaremos a 
um acordo, mas tudo bem, desde que respeitemos a 
perspectiva uns dos outros. 


e Esta em nossas mãos tornar o ambiente de desenvolvimento de 
produtos digitais mais inclusivo. O caminho para isso acontecer 
é trazer o tema à tona e torná-lo parte das conversas. 


Lançamento antecipado e frequente 


e Existe um conjunto de quatro valores que são de fato o núcleo 
de todo time de desenvolvimento de produtos digitais. São os 
valores que compõem a cultura de produto, que nada mais é 
do que o conjunto de comportamentos dos times de 
desenvolvimento de produtos digitais que produzem os 
melhores resultados. 


e As três razões para você lançar logo seu produto são que (i) 
esse é o momento da verdade, (ii) assim você evita o excesso 
de funcionalidades e (iii) acelera o retorno do investimento. 


e Se você não tem vergonha da sua primeira versão, demorou 
demais para lançar. 


e Minimal Marketable Feature ou MMF é um conceito anterior ao 
de MVP, que traz a vantagem de trazer essa mentalidade de 
implementar o mínimo necessário para cada funcionalidade do 
produto. 


Foco no problema 


e Um passo muito importante para criar uma boa solução é a 
compreensão do problema. Quando ouvimos sobre um 


problema, imediatamente começamos a pensar nas soluções. 
No entanto, quanto mais tempo gastamos aprendendo sobre o 
problema, mais fácil será encontrar uma solução e há boas 
chances de que essa solução seja mais simples e rápida de 
implementar do que a primeira solução que pensamos. 


Se você tiver uma lista de projetos para fazer, crie duas colunas 
a mais nessa lista, uma para problemas a serem resolvidos em 
cada projeto e outra para quem os problemas serão resolvidos. 
Isso ajudará você a se concentrar nos problemas a serem 
resolvidos, e não nos projetos, que são a solução. 


Equipes de implementação de solução são equipes trabalham 
na implementação de uma solução concebida por outra pessoa. 
Equipes de solução de problemas são equipes trabalham para 
compreender profundamente as causas do problema, o 
contexto e a motivação que as pessoas têm para resolvê-lo. Ao 
fazer isso, eles são capazes de implementar a melhor solução 
para o problema em questão. 


A armadilha top-down é a percepção do processo de tomada de 
decisão sendo feito pelos líderes da empresa, sem 
oportunidade de participação do resto dos funcionários. Essa 
percepção é exacerbada quando uma empresa enfrenta uma 
pressão crescente, como a crise do COVID-19. 


As pessoas são orientadas para a solução e, quanto maior a 
pressão, mais rápido as pessoas desejam que as soluções 
sejam implementadas. 


Para ajudar a lidar com essa situação, use a empatia para 
entender o ponto de vista do solicitante de implementação da 
solução e pergunte a ele por que é necessário implementar a 
solução solicitada. 


Os heads de produto têm a função e a responsabilidade de 
promover essas mudanças de comportamento para ajudar a 
construir um processo de tomada de decisão mais colaborativo. 


Entrega de resultado 


e Outro valor fundamental para qualquer time de desenvolvimento 
de produto é o foco na entrega de resultado. 


e É preciso tomar cuidado na definição de resultado. Entregar 
uma funcionalidade não é um resultado. Toda funcionalidade é 
um meio que serve para um fim, o atingimento de um objetivo 
de negócio. 


e Mesmo empresas 100% digitais, cujo produto digital e a 
tecnologia são o core da empresa, têm por foco objetivos de 
negócio. 


Mentalidade de ecossistema 


e Mentalidade de ecossistema significa tomar decisões que 
criam valor para todos os atores de uma plataforma. 


e No Gympass, durante a crise do COVID-19, depois de 
colocarmos o Gympass Wellness para todos os seus clientes e 
os funcionários desses clientes, uma parte importante do 
ecossistema ainda estava sofrendo, as academias. Foi a 
mentalidade de ecossistema que guiou o Gympass para criar O 
produto de Live Classes, que permitiu que as academias 
continuassem operando mesmo estando de portas fechadas. 


29.3 Ferramentas 


Aqui vimos as ferramentas que tenho usado nos meus quase 30 
anos de carreira em liderança de desenvolvimento de produtos e 
que tenho compartilhado com outros líderes para que eles possam 


usar com suas equipes. As ferramentas de que falarei incluem 
visão, estratégia, objetivos, estrutura de equipe, métricas, 
relacionamentos e cerimônias. 


Visão, estratégia, objetivos e estrutura de time 


e Visão, estratégia, objetivos e estrutura de time são, além de 
conceitos muito importantes, ferramentas essenciais para 
qualquer head de produto. 


e Para visão e estratégia, uma apresentação com alguns slides 
é suficiente. Para OKR e estrutura de time, planilhas dão 
conta do recado. 


e Mais importante do que os softwares que você utiliza para 
documentar Visão, estratégia, objetivos e estrutura de time é 
o que você faz com essas ferramentas. Planilha de OKRs eu 
uso no mínimo toda semana. Visão e estratégia, sempre que 
tenho oportunidade, eu falo sobre esses temas. Estrutura de 
time, sempre que vamos falar de contratações ou mudanças no 
time, utilizo a planilha de estrutura de time. 


Medindo e gerenciando a produtividade 


e Não existe bala de prata para aumentar a produtividade de um 
time de desenvolvimento de produto. Contudo, existem sim 
duas ferramentas essenciais para ajudar nesse objetivo. 


e A primeira ferramenta é medição. Não há como melhorar algo 
que não se mede. O que é velocidade de desenvolvimento de 
produto? É importante haver uma definição clara dessa métrica 
e consequente mensuração. 


e A segunda ferramenta é trazer o tema produtividade para o 
centro da discussão. Todos do time de desenvolvimento de 
produto são responsáveis pela produtividade do time. Por isso, 
ao trazer o tema para o centro da discussão, todos poderão 
colaborar para melhorar a produtividade. 


Medindo e gerenciando a qualidade 


e Questionar se o desenvolvimento de produto deve ou não ter 
uma equipe de QA dedicada nao é a pergunta certa. 


e O problema que você está tentando resolver é como melhorar a 
qualidade do seu produto. 


e Uma boa métrica proxy de qualidade são os bugs. Inventário de 
bugs, novos bugs por semana e SLA de resolução de bugs. 


e Uma equipe de desenvolvimento de produto deve ter todos os 
seus membros seguindo essas métricas e agindo para melhorá- 
las. 


e Gerir bugs não é suficiente para gerir a qualidade do produto 
digital. Desempenho, escalabilidade, operabilidade, 
monitorabilidade são alguns exemplos de requisitos não 
funcionais que impactam diretamente na qualidade do produto 
digital. 


e A qualidade esta em primeiro plano para fornecer uma boa 
experiência do usuário. Além disso, é fundamental para 
aumentar a velocidade de sua equipe de desenvolvimento de 
produto. Quanto menos bugs uma equipe tiver para corrigir, 
mais tempo ela terá para se concentrar em coisas novas. 


e Organizações de alta velocidade são capazes de aprender 
muito rápido, especialmente com suas falhas, e de absorver 
esse aprendizado como parte integrante do conhecimento da 
organização. 


Métricas 


e As métricas de um time de desenvolvimento de produto podem 
ser classificadas em 3 grandes categorias: internas, de usuário 
e de negócio. 


e Métricas internas mostram como o time está de saúde: as 
métricas de usuário mostram a relação de seu usuário com o 
produto e as métricas de negócio são aquelas que mostram se 
o produto está, de fato, entregando valor para o negócio. 


e Métricas devem ser acompanhadas com a maior frequência 
possível, no mínimo semanalmente. Mesmo se for uma métrica 
mensal, procure acompanhar as parciais semanais, ou mesmo 
diárias, dessa métrica, para dar maior oportunidade de agir 
mais cedo quando houver uma variação de curso. 


Relacionamentos 


e O gerenciamento de expectativas é algo entre 50 a 80% do 
tempo de um head de produto. 


e RASCI é uma ferramenta muito útil para ajudar a definir e 
entender os papéis e responsabilidades de cada pessoa e cada 
função. 


e A matriz de poder-interesse, juntamente com RASCI, é uma 
ótima ferramenta para ajudá-lo a entender melhor e interagir 
com seus stakeholders. 


e Mas não se esqueça, a principal ferramenta que um head de 
produto precisa para entender melhor e, consequentemente, ter 
interações aprimoradas e frutíferas com seus stakeholders é a 
empatia. 


Contratar as pessoas certas 


e O trabalho de contratação de pessoas deve ser feito em 
conjunto com o RH. E um trabalho em equipe. 


e As fases da contratação são definir o perfil, atrair candidatos, 
entrevistar, escolher e fazer a proposta, onboarding. 


e Ociclo de vida de uma pessoa no seu time nao termina no 
onboarding. E importante constantemente dar e receber 
feedback dela, para garantir que o relacionamento funcione 
bem tanto para o time quanto para a pessoa nova no time. 


e Por fim, a última fase do ciclo de vida da pessoa no time é 
quando a pessoa sai do time. É preciso entender os motivos 
que levou a essa decisão para entender como esses temas 
podem ser trabalhados no futuro. 


Feedback e avaliação de desempenho 


e Seis aspectos essenciais para um bom feedback são: checar se 
o feedback é necessário, dá-lo na hora em que acontece, ser 
objetivo, ser transparente, ter empatia e dar o feedback em 
privado. 


e As sete principais características de um bom gestor de produto 
são empatia, comunicação, capacidade de gestão do tempo, 
conhecimento de novas tecnologias, habilidades empresariais, 
curiosidade aguçada e conhecimento sobre o tema do produto. 


e Se o produto não for um produto técnico, não é necessário 
saber programar. Contudo, ter alguma noção de programação 
pode ser útil para entender como seu produto funciona. Saber 
SQL também é útil, pois ajudará a gestora de produtos a 
entender melhor as métricas de seu produto. 


e Processos formais de avaliação de desempenho têm sido vistos 
cada vez mais pelas empresas como algo que não traz tantos 
benefícios como esperado. Várias empresas estão substituindo 
esse processo por conversas mais frequentes entre líder e 
liderado sobre carreira, performance, potencial e valores. 


e Retrospectiva semestral é uma boa forma de ter uma conversa 
estruturada com o liderado sobre os resultados atingidos e 
como eles foram atingidos, e sobre os desafios que estão por 
vir. Essa retrospectiva deve ser construída em conjunto com o 


liderado. Caso haja um processo formal de avaliação de 
desempenho na empresa onde você estiver trabalhando, use o 
processo de retrospectiva para criar a avaliação de 
desempenho. 


e Sobre promoções e aumentos, há dois aspectos a considerar, 
quando e como. Recomendo separar as conversas de aumento 
e promoção das conversas sobre feedback para manter o foco 
total no tema de cada uma dessas conversas. Recomendo 
também promover a pessoa quando ela apresenta o potencial 
de desenvolver as habilidades necessárias para ocupar o 
próximo nível de carreira, e não esperar que ela já demonstre 
as habilidades necessárias para esse próximo nível de carreira, 
pois isso vai motivar mais a pessoa. 


Cerimônias 


e Essas cerimônias com diferentes stakeholders têm por objetivo 
planejamento, alinhamento e gestão de expectativas. 
Saliento que essa lista não é definitiva, ou seja, a depender da 
empresa e do contexto, pode ser interessante criar outras e 
algumas das cerimônias listadas aqui podem não ser 
necessárias. 


e Reuniões de 1:1 são importantes para manter o alinhamento e 
a comunicação com seus liderados, seus líderes, outras 
pessoas do time e pessoas das outras áreas. 1:1 com seus 
liderados e seu líder devem ser semanais e ter reservada uma 
hora de conversa. Já os 1:1 com outras pessoas podem ter 
periodicidade e duração menor, ou mesmo ser eventuais. O 
tema dessas reuniões é livre, e não deve se ater apenas à 
prestação de contas. Envolvem questões pessoais, o dia a dia, 
preocupações, feedbacks, retrospectivas. 


e Reuniões do time de liderança são as reuniões que o head de 
produto faz com os seus liderados diretos. Além dos liderados 
diretos é importante ter a pessoa de RH que está dedicada a 


ajudar o seu time. O tema é livre, mas é importante discutir 
periodicamente sobre os OKRs e sobre as dinâmicas de 
comunicação com o restante da empresa. Devem ser no 
mínimo semanais. Podem acontecer mais de uma vez por 
semana, até mesmo diariamente caso haja muitos temas a 
serem discutidos. 


All-Hands são reuniões com todo o time de desenvolvimento 
de produto onde são comemoradas as conquistadas e 
compartilhadas as lições aprendidas. A recomendação é que 
sejam mensais. 


Product Council são as reuniões onde é apresentado o 
planejamento do próximo trimestre para a liderança sênior da 
empresa, preferencialmente no formato de OKRs. Costumam 
ser trimestrais. 


Product Updates servem para tirar o efeito caixa preta dos 
times de produto e tecnologia. É quando os líderes desse time 
apresentam o que foi feito no último mês, o que será feito no 
próximo mês, como essas entregas impactam nos resultados 
da empresa, demonstrações das funcionalidades e abertura 
para qualquer pessoa possa perguntar o que quiser para o time. 


Reunião de estrutura de time serve para discutir junto com a 
liderança do time de desenvolvimento de produto como o time 
será organizado, como usaremos o orçamento de contratação e 
qual a prioridade de contratação. 


CAPITULO 30 
Conclusao 


Após esse resumão, chegamos ao final do livro. Procurei 
documentar aqui o que tenho aprendido ao longo da minha carreira 
na esperança de ajudar outras pessoas a conhecerem mais sobre 
como liderar o desenvolvimento de produtos digitais. 


Ao longo dos meus 30 anos de carreira, tenho experimentado 
diferentes formas de ajudar times de desenvolvimento de produto a 
atingirem seus objetivos, ou seja, a conseguirem criar e evoluir 
produtos de sucesso. Tenho ajudado não só os times que liderei 
diretamente, como times de outras empresas para quem presto 
serviço de advisoring. Todas essas experiências me proporcionaram 
um campo muito fértil para experimentações e aprendizados. 


Há outras formas de se liderar times de produtos, e algumas podem 
inclusive ter pontos de discordância com o que apresentei aqui no 
livro. Contudo, não existe uma única forma de se fazer as coisas e o 
fato de elas serem diferentes ou até mesmo discordantes não 
significa que alguma delas é errada. Quer dizer apenas que são 
diferentes e cabe a cada um de nós encontrar a forma que mais 
faça sentido para o desafio de liderança que encontrarmos. 


O mais importante é que compartilhemos nossos aprendizados, 
mesmo que discordantes, para podermos sempre evoluir essa 
disciplina tão nova que é o desenvolvimento de produtos digitais. 
Não faz nem 100 anos que essa ciência começou, somos um 
recém-nascido se comparados à matemática, engenharia, medicina, 
astronomia e tantas outras ciências que existem há milênios. 


30.1 Vamos continuar a conversa? 


O fato de estarmos na 1? infancia do desenvolvimento de produtos 
digitais significa que ha muito ainda para aprender e experimentar. 
Esses aprendizados e experimentações precisam ser 
compartilhados para ajudar outras pessoas a conhecerem mais, 
experimentarem, concordarem e discordarem para que possamos 
fazer a arte e a ciência de liderar produtos digitais evoluir cada vez 
mais para produzir produtos cada vez melhores e mais úteis. 


Eu vou continuar compartilhando em http://gyaco.com. Incentivo 
você a também compartilhar sua experiência e seus aprendizados 
sobre liderança de desenvolvimento de produtos digitais! Estou 
ansioso para aprender mais! 


